Now that the Saturn128 Reboot design is complete and mostly sold out I am considering designing a new card, this time a ROM card.
My current plan is to make it compatible with the old Apple ROM card that was released to allow the Apple ][ to have Applesoft ROMS soft switchable and for the Apple ][+ to have integer basic. The original cards used 6 ROM's and a handful of TTL chips, there was a toggle switch to select if the card was active or inactive on reset so you could select which basic was the default. My card will go one step further, in addition to the original functionality it will include both version of basic, the original f8 monitor and Autostart ROMs as well as a dead boot diagnostic ROM I wrote that helps identify faulty RAM that would ordinarily prevent a machine from booting (garbage on screen no beep). There will be room to fit another 3 F8 ROM images, so if anyone has any worthwhile candidates to add let me know. The active version of basic and the F8 ROM will be selectable via dip switches on the card. The card will be similar in size to the Saturn128 reboot card and have a comparable chip count, so it wont be particularly expensive to make.
My question is how many of you would be interested in a card that will serve as a very handy diagnostic and still be useful when your Apple isn't broken?
Hi Dave,
I have an Apple ][ + rom set that I made that covers the lower case additions (minus the char ROM, but I can include that but it must be installed on the Main board)plus a few other mods that I can list for ya when I dig up my documentation. Put me down as interested in the board too.
Very interested. I would guess a lot of people will be.
At this stage the schematic in my head has the following part list....1 x 27256
1 x 4 way dip switch
1 x 74ls74
1x gal22v10
1 x 1n4148 diode
5 x 10k resistors
1 x pcb mount toggle switch
Because of the GAL speed it may have timing issues in some clones.
An alternative is to not use a GAL just TTL chips. That design will need an extra 4 or 5 TTL chips (still working out the decode logic in my head) but should not have any timing issues.
The TTL design will need to be simplified a bit also so only 3 different F8 images selectable for each of the 2 basics.
Another option is to use an EEPROM rather than an EPROM. The design could enable the write line via a removeable jumper that would allow shadow writes to the EEPROM and avoid the need for an EPROM programmer. So basically you would configure the cards dip switches for basic and f8 image you want to write and with the card disabled, run a program that writes to the ROM memory locations from an image stored on disk with a suitable delay between each byte. If somebody wants to do that let me know and I can include the hardware changes in the design.
I am definately interested in one of these also.
Cheers,
Mike
David, making the card permanently writeable using an EEPROM would be outstanding. (!) That's one of the functions I wanted to work out years ago but never got to.Not sure what hardware you plan to use for bank selection, but having at least 2 or 3 D0-F8 selectable banks via a hardware switch, plus 1 selectable (programmable) EEPROM bank would be the ultimate for an Apple II / II+ ROM Card. Adding a RTC (clock) option would also be nice if you could build addressing for it. (thinking out loud...)Ian Kim did a similar card for bank selection and included the battery-backed clock in his "Hyperion" card.My plan is to keep it simple and low cost. Adding a RTC will probably increase the component cost by a factor of four, reduce compatibility with the original card and require custom drivers.
From memory the hyperion card used a fpld which also makes it more difficult for a hobbyist to make (surface mount soldering). I don't want to design a card that will need to be sold fully assembled for $100.
Just so we are clear making the card writable is not that same as using it as non volatile RAM storage. EEPROM has a finite number of write cycles and using it as RAM would kill it before too long, the write cycle time would also be too slow for the purpose. Making it user programmable is a simple enough feature to add, it only requires a pull up resistor and two 2 pin jumper block The EEPROM would only be programmable while the jumper block was shorted.
I made a start to the layout, still a few components to add like resistors, capacitors and the write enable jumper block and of course most of the schematic.
I was intending to upload the 3d render of the layout but the option to add attachments seems to be missing.
I've got a Minipro TL866CS so I'd be O.K. with a card that used EPROMs. I usually keep 2716 to 27512 chips in stock, so that's not an issue either. I would be O.K. with an EEPROM based card also I guess, but EPROMs are cheap, simple and easy enough. I think you are on the right track of keeping it simple and inexpensive. Kit or bare board is cool too, I'm not afraid of soldering.
Adding the write option will only add one resistor to the component count for those that choose to use an EPROM the 2 pin header and jumper block wont be needed.
I'll add the option to the board and if somebody wants to write the code to support it great and if not no real difference in cost to have it there unused.
What do you think about a SRAM instead of an EPROM? Writing could be disabled by Jumper, the content will be saved by a CR2032 or similiar.
Regards
Ralf
I kinda favor the EEPROM version myself. Simple, inexpensive, no batteries. Not that batteries are expensive, but it does add complexity.
BTW Dave, my thoughts on the clock were only a thought (i.e. thinking out loud) in case you were looking to expand functionality.
I like the simple multi-select option you describe for selecting "banks" of D0 thru F8.
A lot of us have modified the Apple ROM card to accept 2732 EPROMS and used the toggle switch to select 2 banks, but it would be really nice if those banks were re-writeable, especially if 4 banks were presented. That would be a really cool card to have.
Opinionated note: EEProms are rated in the 100,000 of R/W cycles, and unless you write a program to do that with the purpose of exhausting an EEProm's life cycle, I don't think you should discount the idea of EEPROMS in your circuit. I have a lot of experience using EEPROMS in industry and they last a long time with dozens of R/W cycles every day. If I were to average 20 changes per day, every day of the year, it would take over 13 years before the EEPROM reaches it's max rated R/W duty cycle. Can't speak for everyone but I think that should be good enough.
I'm not sure I'd want to use SRAM even if battery backed because while the battery may last a long time, the fact that a dead battery will cause an unbootable machine makes it a lot less attractive a solution to me. I think the solution of supporting either EPROMs or EEPROMs with a jumper would be satisfactory for most uses. Anyway, there are already battery backed RAM devices like some of the RAMFactor and Slinky clones that are already out there. Those devices are already intended to be used like RAM.
There is a very good reason for the write enable jumper. EEPROM can be written many times that is true however the enable method Apple used on the ROM card is the same as they used for their 16k RAM card. The way a RAM card is detected is to write to it and then read back the locations to see if the values are what was written.
So what that means is every time you run software that supports more than the base 48k of memory your ROM image will be corrupted. Some software will detect a write enabled EEPROM as a RAM card. If that happens it wont be 20 writes a day it will potentially be thousands of write cycles a minute.
A 27c256/28c256 will provide 2 x 12k banks not 4. Each 12k includes a 2k boot and each bank has 4K spare (normally at c000-cfff) that is remapped into the f800-ffff memory space giving a total of 6 selectable boot ROM images. If i went with 4 x 12k banks that gives 12 2k boot images.... overkill and double the card size because there is barely room to put the switch settngs on the silkscreen overlay now.
For those that want a battery backed RAM card, the Saturn128 Reboot is easily modified to do that. Just Isolate pin 32 of the RAM chip by cutting the track on the top of the PCB at the edge of the pad. place a blocking diode across that cut you made oriented so that pin 32 is powered when the system is switched on. Then mount a button battery holder on the back of the card +ve to Pin 32 and -ve to pin 16. The blocking diode is there to prevent the battery supplying power to the whole system when powered down and to prevent the non rechargable battery getting a charge voltage when the system is switched on.
Here is the current layout, there will be two more resistors added, the write enable header and the capacitors, but it probably wont change much.
https://drive.google.com/file/d/1HntIJP-wlUHX_1lRG_m-HT8LxpeUQsbI/view
Adding a location for a jumper and pins to connect a battery would be a cool addition to the Saturn 128 reboot if you do another run of boards. I agree that it is a far better option for a battery backed RAM solution than your ROM card project for just about any purpose I can think of.
[quote=softwarejanitor]
Adding a location for a jumper and pins to connect a battery would be a cool addition to the Saturn 128 reboot if you do another run of boards. I agree that it is a far better option for a battery backed RAM solution than your ROM card project for just about any purpose I can think of.
[/quote]
I still have 6 bare board and another two fully assembled to sell so its not likely I'll do another run anytime soon. But it is one of the things I considered adding if I eventually do another run.
Consider using a single rotary BCD switch for all selections, something like:
https://www.alibaba.com/product-detail/Right-Angle-2-54mm-Position-4_60438355790.html
The switch can be mounted in place of the toggle you have on your layout with the stem pointing upward. The DIP SW goes away.
Position 0 can be AppleSoft or whatever is on the motherboard, position 1 can be Integer Basic, etc. etc.
One switch does all. Points upward with a short stem. This also gives you more room if you want to increase the EEPROM to a 28SF040. And I can assure you there's enough F8 variations out there to fill it.
Just a suggestion...
You might advertise your boards on the Facebook Apple II Enthusiasts and Apple II For Sale groups. I bet they wouldn't last long. I bought 3, so I don't really need any more. :-)
The schematic design and layout are now complete.
I'll wait a couple of days and recheck it with fresh eyes before sending the files in to have prototypes made.
This is what it looks like.
https://drive.google.com/open?id=1RNHg_Qyr4S5p-H31DuBLPMv2azW6WqhZThia one measures 66mm x 66mm so its slightly larger than the Saturn128 Reboot which measured 66mm x 60mm. I needed the extra 6mm in height to fit the text for the dip switch settings. Component cost will be about $10. The cost of the board will depend on the number of presales. Gold plating adds a fixed setup cost so the more boards run the cheaper each one is. If there are not enough orders and the price is looking too high per board then having them run without the gold edge (HASL) will bring the price down under $10.
Update: After checking with fresh eyes this morning I realised the the drill holes in the footprint I created for the toggle switch were too small. Hopefully the footprint is right now.
I didn't find any other issues so I generated the gerber files and ordered prototype boards. With DHL express delivery they should arrive Friday or perhaps Monday.
Dave, any thoughts on using a single binary switch as suggested in my post above? Saves real-estate, cost, and allows use of a larger EEPROM. The silkscreen on the board is nice, but can be consolidated by indicating the PLANNED hardware positions, and (say) Position 3 thru 9 being used defined. (if you know what I mean) You should have plenty of space for those changes, and I would be willing to help fund the effort.
Many Apple ][ Collectorshave a pretty significant investment in their collections. While it's good to keep prices down for the masses, don't let that steer the effort far from the main goal.
DEFINATELY keep with gold contacts. It's worth the added cost IMHO. If there's a shortage, let me know.
The problem with using the binary switch is the basic version needs to be selected independently of the F8 ROM. I would need a 1 way dip and a 3 bit binary switch.
Using a single 4 bit binary switch the table would be too complex ie.
0 - applesoft with autostart
1 - integer with autostart
2 - applesoft with monitor
3 - integer with monitor
4 - applesoft with diagnostic
5 - integer with diagnostic
6 - applesoft with User1
7 - integer with User1
you see where its going.....
The other idea you raised was increasing the size of the ROM, each time the ROM size is doubled I need 2 additional dip switch positions, 2 resistors, 2 additional GAL inputs and one additional GAL output pin. I have 3 pins spare on the GAL in the current design and room to squeeze in the resistors and a 6 way dip switch but no room for the doubling of the switch settings tables.
The other potential limitation is the number of product terms in the GAL. I haven't written the code for the address line remapping to place ROM in the 4k hole (C0 and C8) at F8, so I'm not 100% sure the current design will have enough product terms. Double the EPROM size will double the number of product terms required.
If I don't have enough product terms for the current design, my fall back position is to mirror the F8 images in both the upper and lower half of the EPROM, dropping the 3 user defined images. So the F8 options will be Autostart, Monitor, Diagnostic and motherboard. That will halve the product terms needed and free up one position on the dip switch, position 4 will become write enable replacing the header J1.
OK, I didn't realize you were separating the F8 Rom space from the rest. I guess I slept through that part... :( I thought you were creating selectable banks that cover the entire D000 thro FFFF ROM space as a unit, so I think I better understand the project now.
Just going to throw it out there, but wouldn't it have been easier for you to simply select EPROM banks and let the user dump whatever they want into those banks? (rather than separating the F8 Rom space) I understand the reasons for separating the F8 code space, especially if you're using EEPROMs, but if you're simply addressing whole banks that you're going to custom make anyway, does it matter? Or is this more for folks who don't have ability to program their own EPROMs and you're making a card that has the more popular code sets with selectable F8?
Either way, I see the value. Thanks for explaining above.
When I initially decided to make a ROM card I planned on a single ROM because it is cheaper than the 6 2716's of the original design and easier to source.
From there it was a small step from just having integer to why not cover both bases. The extra F8 images came about because I thought why waste that space.
I also looked at the way I use the ROM card I have, that is to use a diagnostic ROM when I'm repairing Apple 2 or Apple 2+ because I cant use a 2716 directly in the motherboard.
The guidelines I used designing the card was to keep it small simple and affordable while appealing to the widest possible audience.
The reason people are likely to want/need a ROM card played a part also.
People with a 2 wanting Applesoft
People with a 2+ wanting integer
People wanting a way to run the diagnostic ROM in a 2 or 2+
People with a clone needing the screen to display "APPLE ][" so they can run unpatched ProDOS.
Then I thought some people are purists that will want the original Monitor with their integer, others will want the convenience of Autostart. Some people may want both at different times and not want the hassle of reprogramming their card.
Yes it would be easier to just bank select but it would have been less flexible and more costly, To get the same combinations of basic/F8 ROM as the 27256 in this design I would need a 2Mbit ROM using bank select.
Plus for those that need more.. I can sell them two cards lol
I think the card as you have envisioned it solves the problems that most people have. Especially if people build an EEPROM version, I think there is more than enough flexibility even when it is kept pretty simple.
[quote=softwarejanitor]
I think the card as you have envisioned it solves the problems that most people have. Especially if people build an EEPROM version, I think there is more than enough flexibility even when it is kept pretty simple.
[/quote]
I worked for many years contracting as a programmer, I know well the dangers of scope creep. So I set fixed goals to aim for as well as a lesser acceptable solution before starting to layout the schematic.
One suggestion was adding a real time clock, I noticed that the Epson chip is currently available on ebay for $1 and is still available from Digikey and Mouser ($10). So maybe a RTC card will be a future project.
I'm working on a card that has a RTC on it, along with a high speed serial port (large FIFOs) and a WiFi chip. It uses a very different design than most other Apple II cards though. It actually has 2 high speed serial ports, one is used for the WiFi. There are existing 6551 (SSC) based WiFi solutions, but the oerformance of the 6551 stinks because it only has 1 byte send/receive buffer, vs 64 bytes for the chip I'm using. The RTC sort of comes along for free because it is so easy to tack on to the interface chip.
I am interested in a couple of them. One option to consider is Mike Willegal's Apple I "emulator" ROM for the Apple II, like the one on the brainboard. He released source for it and probably would not mind...
I have it in my homebrew ROM replacement board and it works fine. My hack is not a card, but just an EPROM on a perfboard that plugs into the D0 ROM socket and the 74LS138 next to it to get all the signals.
Mike uses the ROM holes to provide the Apple 1 functionality. I am using that space in the eprom for the extra boot rom images so it can't be done.
[quote=David_M]Mike uses the ROM holes to provide the Apple 1 functionality. I am using that space in the eprom for the extra boot rom images so it can't be done.[/quote]
Just out of curiosity, can you explain "ROM holes?" :)
From the Wozanium Pack description:
----
Also included in this zip package, is a ROM file suitable for emulators, such as Virtual II. This allows you to run and debug Apple 1 software in the Apple II emulator environment. Just select the .ROM file as the ROM for your machine and reset your virtual machine. Just as in the Brain Board, right arrow will clear the screen. Using the emulated cassette interface built into Virtual II, you can download AIF files of A1 basic and assembly language programs and run them in your emulated Apple II. Note that this ROM version does not include the ACI driver at C100, so you must enter the cassette driver by entering “D000R”, instead.
----
I have loaded this ROM onto my Apple II EPROM board, and of course ACI is not usable at C100, but at D000 instead. It seems to work, I don't have any extra circuitry...
To run it that way just replace either Applesoft or Integer with the ROM Mike released for emulators and it should work.
The prototype cards arrived today and I've assembled one of them. I think I will move the JP1 header below the dip switch and rotate it 90 degrees for the production boards.Now I need to find the time to start writing the GAL code.
20180924_151202[1].jpg
Looks nice! Should be a great board to have. I'm thinking it would be perfect in one of the clones that I have so I can run the original EROMs, or "real" Apple Applesoft or Integer ROM images. Plus space for experimentation.
Dave,
Suggestion:
Move your "MultiRom & signature line" up slightly, then add a left arror underneath and indicate "Toward Keyboard" or something to let folks know the board direction.
You should change the resistor array to a SIP device. Saves you a lot of room & easier to assemble.
Not sure you can leave a tiny bit more room for the decoupling caps. I thought the jumper location looks fine, but if I were to change it, I would make it accessible from the top so a programmer can lock the write pin before powering down the computer.
Over the top suggestion: If you have a flip-flop available in the 74LS74, add a bi-color LED that indicates Green for board enabled, (not set to motherboard position) Amber for not write protected. :)
Looks good, BTW...
[quote=macnoyd]
Dave,
Suggestion:
Move your "MultiRom & signature line" up slightly, then add a left arror underneath and indicate "Toward Keyboard" or something to let folks know the board direction.
You should change the resistor array to a SIP device. Saves you a lot of room & easier to assemble.
Not sure you can leave a tiny bit more room for the decoupling caps. I thought the jumper location looks fine, but if I were to change it, I would make it accessible from the top so a programmer can lock the write pin before powering down the computer.
Over the top suggestion: If you have a flip-flop available in the 74LS74, add a bi-color LED that indicates Green for board enabled, (not set to motherboard position) Amber for not write protected. :)
[/quote]
The production layout already marks the keyboard end in the same manner as the Satrun 128k reboot card. I moved the caps in the production when changing the footprint to 5mm lead spacing, I selected the 2.5mm spacing footprint by accident when I laid out the prototype.
The trace routing is pretty tight between the decoupling caps and the resistors but I can't put he resistors anywhere else. There are 130 nodes and only 7 via's so the layout is pretty optimal. When I laid out the deisgn I deliberately made a decision not to use a sip package for the resistors, one of the design rules I followed was to make the board low cost with easy to source components. 100 resistors for less than $1 on ebay compared to the cheapest 9 pin 10k sip pack price of 20 for $5 made the choice a no brainer.
I decided to move the dip switch down a little rather than the jumper header for trace routing simplicity.The LED idea wont work with the way I've done the design. Write signal is not buffered or routed via the GAL to avoid timing issues, the write input of the EEPOM has a 10k pullup and the R/W signal from the slot is either connected or isolated by the jumper. As for an enabled LED they is no clean way to route the trace from the latrch to a place on the card for the a LED and resistor that woiuld not look out of place.
Not sure cost is a valid reason for separate resistors because you can get 20Pcs of a SIP Resistor pack for $2.60. Makes more space for you, less soldering and component placement, etc. I don't think the extra dollar or so will discourage anyone. Example: (and I dont know the actual value of yours...) https://www.ebay.com/itm/351588189037/
But it's just a suggestion. Maybe too late because you've already submitted the design?
With regard of indicating an instert direction, YES it makes sense to a lot of us but without marking the direction somewhere, some will surely plug it in backwards. Some boards do have components on the back side. Folks getting this board and not the RAM board would not know about this ... again, just a suggestion.
Can you share a screen shot of your schematic?
I'll make the schematic available once prototyping is complete because component values are not in the schematic yet and things may change before I'm ready to do a production run. I'm also busy writing the GAL code, its kind of working but some dip settings are not working correctly. There is a logic bug there somewhere that I need to track down. For instance Autostart works with both applesoft and intbasic but user1 always uses applesoft even if intbasic is selected. The F8 disabled mode works and I can power up with the 2e's onboard F8 but using either applesoft or intbasic on the card. I haven't done any tests for timing compatibility or added the DMA daisy chain code to the GAL yet. It's 4am here now and the logic bug will be easier to locate when I'm better rested.
Edit: The sip pack value is 9 pin 10k , its in the message where I mentioned the price of them
Get some sleep man!
Just in case ... ;)
https://www.ebay.com/itm/332205765164/
Good news! I pulled an all nighter and completed the GAL code.Everything works all six F8 images and the motherboard F8 can be selected to work with either version of basic. The DMA daisy chain code is also implemented and working. I'm removing the write option from the production version because it doesn't work. If anyone wants one of the prototypes with the write option to try and make it work, let me know and you can have one for $6 plus postage. I've only tested in an 2e platinum so far but because the mapping is based on a GAL just like the Saturn card so I don't anticipate any problems. The Saturn card has support for daisy chaining the DMA even though Apple never did it on their RAM cards, but I think there is a bug in the Saturn GAL so I will fix that and upload new GAL code for it before the ROM cards ship.
For those that want to get a head start on creating a custom ROM for the card, this is the ROM map.
0000-07FF - User 2
0800-0FFF - User 3
1000-37FF - IntBasic including programmers aid
3800-3FFF - Monitor
4000-47FF - User 1
4800-4FFF - Dead boot diagnostic
5000-77FF - Applesoft
7800-7FFF - Autostart
If anyone wants to pre order, US$10 + $3.50 postage, PM me for my paypal details. I have extra toggle switches for $2 if you want one shipped with the card. If anyone wants a kit of parts or a built and tested card PM me. I'll order production cards in the next couple of days but they will take longer than usual because they have a weeks holiday in China.
Update:
I decided to order new boards today to get then run before they go on holiday (hopefully). I'm also using a different manufacturer this run and thought having them made in black rather than green might make them stand out from the nearly identically sized Saturn 128k reboot cards. Apparently the big shiny switch on them was not enough for me to tell the difference because i kept picking up the wrong card while testing.
I have uploaded the Schematic, EPROM and JED file here.
MultiROM Files
I have also fixed the DMA daisy chain bug in the Saturn128k reboot. For daisy chaining to work with a ROM card the Saturn card/s must be in slots with a lower number that the ROM card and there must be no gaps or the daisy chain is broken and the ROM card will not disable itself while a RAM card is active. Atmel GAL's require a 10k pullup resistor between pins 24 and 11 of U2 (GAL), Lattice GALS do not require the resistor. Here is the link to the fixed GAL code.SATURN128K_REBOOT - GAL22V10 - DMA_Fixed.jed
Update 2:
The boards have been made and are wating for DHL to collect them. So possibly a Monday delivery.
The boards have arrived and work as intended.
They are ready to ship now bare boards are US$10 + $3.50 postage.Get in fast these are the "Black Label gold plated edition" lol
multi2.jpg
Just sent payment for 2 in black, 1 proto. Forgot about the switch though ...
I hope you still have some on Friday... I'm broke until then unfortunately.
HI David,
Will the board work if there are no ROMs on the motherboard installed at all?
(I have one with bad sockets)
[quote=macnoyd]
Just sent payment for 2 in black, 1 proto. Forgot about the switch though ...
[/quote]
3 boards on their own hit the weight limit for the cheaper postage. The only way I can send the switches without them tearing through the bag or being too thick to post asd a letter is in a board and held in place with tape. You may have to source them locally.
[quote=rittwage]
HI David,
Will the board work if there are no ROMs on the motherboard installed at all?
(I have one with bad sockets)
[/quote]
Yes the board disables the motheboard ROM's when it is active.
[quote=softwarejanitor]
I hope you still have some on Friday... I'm broke until then unfortunately.
[/quote]
I ordered 30 and they shipped 34, so yes plenty of boards. I doubt I'll run out any time soon.
I have just discovered a problem with the MultiROM card. I was unaware that the 27256 and 28c256 have a different pinout. The PGM and A14 pins are swapped, so only half of the chip is accessible if you use an eprom.
The card works fine with a 28c256 eeprom.
If you have already ordered the card and it is a problem for you please let me know.
I will update the parts list accordingly.
Dave, is your plan to add a solderable jumper arrangemet to correct this? Or do you have another plan?
You can always specify the28C256 chip and be done with it too , as they are about $1 each and readily available.
Pages