Jump to content

ZaneKaminski

6502
  • Content Count

    148
  • Joined

  • Last visited

Recent Profile Visitors

342 profile views
  1. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    Well, unique addresses as seen by the ROM sockets, so 16-bit words. I will assume for now that we can locate the I/O registers at the end of the ROM where the initials are and finalize my thoughts into a spec. I figured that we would ship the Mac Plus/512Ke ROM on all boards, thus upgrading 128Ks and 512Ks to "e." It will be very tricky to load the driver from ROM, but it can be done. We will have to bank-switch some of the ROM out to access the SD card driver and copy it to the system heap on boot so that it can be called in the normal way.
  2. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    Update: As I said in my last message, I scrapped the previous design and redid it to use a microSD: The microSD slot is on the bottom left of the board. (shown without a 3d model) @Dog Cow In order to finish defining the SPI interface used to talk to the microSD, I need 4-8 spots in the 512Ke/Plus ROM which are "don't cares." These locations will serve as I/O registers to operate the SPI interface. You seem to have done more software work with the Macintosh 512ke/Plus than I have, so maybe you can pick 4-8 addresses to try for this purpose, preferably contiguous. Then we can modify a ROM to garble the data at those addresses and make sure it works in Mini vMac.
  3. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    Here’s the link: https://www.applefritter.com/content/five-new-opensource-appleii-cards-coming-soon-we-need-your-help RAM2E is gonna be released in a week or two, having been tested by several others with no problem. GR8RAM and Time Machine are working in my lab but one tester reports an incompatibility with the CFFA3000 card, which is currently out of production and I can’t obtain, so they are held up. Mouserial and Library Card are next on the list to finish, but they both have an MCU, which makes them more complex. As for this project, I completed the new layout with the additional SRAM for 512k compatibility but I didn’t like the cost, especially once I added the proper type of DIP headers. So I will be redoing it to use a microSD card, at the expense of being a bit slower. The CPLD on the board will implement a straightforward SPI interface between the Mac and the microSD card running at 25 MHz, so the peak bandwidth will be 25 Mbit/sec or just over 3 MBytes/sec.
  4. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @Dog Cow Great. The new layout is approaching completion: My goal is to have the board finished in the next day or two, but it will be another 2-3 weeks until I have boards fabricated, and then another week or two to receive the boards. While the board fabrication is being done, I will prepare a datasheet to describe how software on the Mac is to interact with the card and its serial flash memory.
  5. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    I have resolved to scrap the current ROMBUS boards and layout and do a new revision of which should be compatible with the Mac 512k. I have switched to a physically smaller CPLD (the somewhat ancient MACH5LV, but I can source 1000+ of them for cheap) and switched the ROMs to surface-mount to make room for two 128k x 8 SRAM memories, providing extra room for the Mac 512k driver to store tables and other information. Here is a shot of the board, unfinished. I am currently laying it out and I will be sending it to production with my next batch of gizmos in a month or two: This picture of the board still has the socket spacing for a Mac Plus, but it will be trivially easy to stretch out the right side of the board so as to fit in the wider socket spacing of the Mac 512k. There is only one gotcha. the Mac 512k has the ability to address 128kB of ROM, and the Mac 512k has only 64kB, so we have an extra 64kB to store the ROMBUS driver. But the Mac 512ke has a 128kB ROM, and there is no provision to address 256kB of ROM like in the Mac Plus. If we intend to present the enhanced 128kB ROM to the Mac 512k, we will have to do some very careful ROM mods and use bank-switching to access the ROMBUS driver. Otherwise we will have to basically downgrade to the 64kB non-"e" ROM, which would really suck since there is no 800k disk support. @Dog Cow With the potential for Mac 512k compatibility, would you interested in developing the driver?
  6. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @olePigeon Certainly there can be some software to change the boot icon in the ROM. As for on the board, maybe, but I have been trying to pursue a really sparse visual style for the boards I've been making. The #1 rule is no URLs, since that basically ruins any hope of making the board look like it's from the right timer period. I will consider the pirate logo. @Dog Cow I appreciate the interest. I'm afraid the ROMBUS won't work on your Mac 512k though. Is that okay? Do you have a Plus? At the very least, to work with the 128 and 512, I would need to do a new board with the correct pin spacing for the 128/512's ROM sockets. That's easy. The more difficult thing is the way I envisioned the ROMBUS driver working. In my driver design, there are 256kbytes of RAM spent on a table to store the block mapping between logical and physical sectors. This is required to maintain the endurance of the flash and to erase flash sectors in bulk, minimizing erase time overhead and speeding up write operations. This same algorithm was first conceived for a yet-unannounced Apple II card I am working on which incorporates flash storage. That card has some dedicated RAM on it to store the block mapping. Maybe I can come up with a different algorithm more suited to the Mac 128/512 and ROMBUS that takes less RAM to store the block mapping. Let me think about it more. Anyway, unless someone comes along and starts developing it, the ROMBUS driver has to wait for me to finalize hardware for some other projects. I have the 5 new Apple II cards I mentioned earlier which I am trying to get released so that others can help with the drivers, plus some gizmos for Game Boy and Commodore 64. Source will be on GitHub in a few days.
  7. ZaneKaminski

    E-Machines Big Picture Card w/Mac SE Interconnect

    The ECL circuitry on the E-Machines card caught my eye. Nice!! That kind of circuitry was once the choice of high-speed test equipment, mainframes, military radar signal processing electronics, etc. I can see two 10H141-series shift registers, a 10H016 counter, and a 10H131 flipflop, all to shift out the video bits it seems. Evidently the designers felt that the typical 74F or whatever was the fastest TTL available at the time was not quick enough, thus the choice of the faster and more power-hungry ECL chips. It's pretty unusual to see ECL in microcomputer stuff, in my opinion. Digital scopes and other high-speed test equipment up until recently has typically had a bit of ECL circuitry but I think this is the first time I've seen the 10xxx series of ECL logic chips in a microcomputer.
  8. ZaneKaminski

    Is an inverter bi-directional: 74LS04 specifically?

    Wait, no, there is a slight problem. I have an idea to solve it. One sec. edit: fixed. Edits are shown in bold in my previous post.
  9. ZaneKaminski

    Is an inverter bi-directional: 74LS04 specifically?

    I skimmed through this quickly so let me share what I know about this stuff, starting with the FC3 signal and the 24/32 bit LC address maps. The original Mac LC had a 68020 and no MMU. Although the addressing capability of the 68020 is 32 bits, a scheme like in the Mac II is used, where the top 8 address bits are ignored to make the system compatible with 32-bit-dirty software. Unlike the Mac II, however, there is no "Apple HMMU" chip which performs the address translation. Instead, the FC3 signal is high only when the system is operating with 32-bit addresses on the physical bus. Decode logic in the onboard chipset and expansion cards must use the FC3 signal to decide whether to decode an address as a 32-bit address, or whether to ignore the top 8 bits and treat it as a 24-bit address. The later LCs had 68030s with an integrated MMU. They always configure the integrated MMU to output 32-bit addresses onto the bus. Thus the FC3 signal is always driven high in the later LCs. This is shown here in the block diagram of the LC: One more thing about the LC PDS and the LC series' address map. The earlier LC PDS machines have a 96-pin connector that does not carry the entire address bus. The LC III and the 68040 LCs added another little connector below to accommodate more address lines (and thus a larger main memory capacity). Looking at the LC's address map, you can see that given a 32-bit address, the device to be accessed can be uniquely identified by A31 and A23..0: So the consequence is that some signals between A31 and A23 can be left off of the PDS connector. In particular, A31 and A27..A0 are sent to the LC PDS card, with A30..28 excluded. On an LC PDS card, here is the circuit to generate the card select signal, as you can see, totally independent of A30..A24: To interface an LC PDS card to an SE/30, the solution goes something like this. We must run in 32-bit mode by tying the LC PDS card's FC3 high. Like the later LCs, the SE/30 only outputs 32-bit addresses onto the bus, as the 24-to-32 translation is done internally in the 68030's MMU. Then we map SE/30 address $FCXXXXXX to $FEXXXXXX on the card by inverting A25. Also, since in 32-bit mode, the selection of the LC PDS card can be done based just on A31, we must also gate A31 such that A31 is 0 when an address not of the form $FCXXXXXX is on the Mac side of the address bus. When the LC PDS card does DMA, we must send back what it drives onto the address bus exactly, with no inversion. We also need to send A30..28 back to the SE/30, since the LC PDS card does not have those pins. DMA devices rarely access peripherals, so we will reconstruct A30..28 as if the LC PDS card is commanding an access to RAM. If we send back all 0's for A30..28 during a DMA transfer, this forces an access into the range of either $0XXXXXXX or $8XXXXXXX. $8XXXXXXX is NuBus extended slot space in the SE/30, which is empty, and also an LC PDS card is unlikely to perform a DMA access with A31 set, since that means the card would be trying to access itself using DMA. $0XXXXXXX refers to the first 256MB of the 1GB assigned to RAM in the SE/30. Since the SE/30's memory controller can only address 128MB, we're good. I wrote a tiny bit of PALASM which should allow you to accomplish this in a GAL: ;PALASM Design Description ;---------------------------------- Declaration Segment ------------ TITLE LC to SE30 PATTERN REVISION 0.1 AUTHOR Zane Kaminski COMPANY Garrett's Workshop DATE 07/19/19 CHIP _LCTOSE30 PALCE16V8 ;---------------------------------- PIN Declarations --------------- PIN 2 /BGACK ; PIN 3 MacA27 ; PIN 4 MacA26 ; PIN 5 MacA24 ; PIN 12 MacA25 COMBINATORIAL ; PIN 13 CardA25 COMBINATORIAL ; PIN 14 CardA31 COMBINATORIAL ; PIN 15 MacA31 COMBINATORIAL ; PIN 16 MacA30 COMBINATORIAL ; PIN 17 MacA29 COMBINATORIAL ; PIN 18 MacA28 COMBINATORIAL ; ;----------------------------------- Boolean Equation Segment ------ EQUATIONS ; During DMA, output A30..28 = 0, A25=A25, A31=A31 back to Mac MacA31 = CardA31 MacA30 = 0 MacA29 = 0 MacA28 = 0 MacA25 = CardA25 MacA31.TRST = BGACK MacA30.TRST = BGACK MacA29.TRST = BGACK MacA28.TRST = BGACK MacA25.TRST = BGACK ; When DMA not occurring, output inversion of MacA25 to LC PDS card ; and gate CardA31 with MacA==FCXXXXXX CardA31 = MacA31 * MacA30 * MacA29 * MacA28 * MacA27 * MacA26 * /MacA25 * /MacA24 CardA25 = /MacA25 CardA31.TRST = /BGACK CardA25.TRST = /BGACK ;------------------------------------------------------------------- Try compiling that with PALASM in DOSBOX. Maybe there are some mistakes but the idea is right, I think. You could also try to work in a more sophisticated IRQ scheme into the PAL somehow. There is one spare output pin in the GAL16V8 so hopefully you can fit it all in the little GAL. Otherwise try the GAL22V10 or a larger CPLD like an Atmel ATF1500-series or an Altera MAX7000S-series.
  10. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @maceffects Oops, somehow I missed your comment. I don't wanna be paid anything upfront... I don't like doing business that way. It would be much better to collaborate on a gizmo and then we can split the profits. Does the PDS card you are trying to run do DMA? If not, you can unidirectionally invert a single address bit so as to change the slot address using a 74HCT04 (or AHCT04, avoid 74HC04, 74AHC04, 74AC04, 74ACT04, 74LVC04). If the card does DMA, that is to say that it drives an address onto the bus, thus commanding an access to memory in the Mac, you must send the address back to the Mac unchanged. You can do this and the inversion very easily with a GAL, I think. Well, the so-called GAL has been discontinued by Lattice, but you can get another version of the same thing, ATF16V8, from most IC suppliers and this will solve your problem if you can manage to write some logic equations to describe the functionality I just described. Use PALASM in DOSBox to do this. I'll make the board, assemble it, and program the GAL for you if you do the design work. @Gorgonops I read your comment again and maybe now I see what you mean about the 32-bits per cycle. One access to the flash register location generates a single clock pulse (low-high-low), so the only limitation is that you can only begin reading on 32-bit-aligned boundaries. There is no PLL or anything like that, so you can send the clock pulses as irregularly or far away as you want, as long as you keep to the 5ns or so minimum clock high time. So if you wanna load an odd 16-bit word from the flash, you twiddle the bits in software to send the command and address the same way as for reading the preceding even 16-bit word. The difference is that you must perform one additional read and discard the result, thus ignoring the even word. Then the 68000 can read data out of the same register location at 16 bits per one read access to the ROM, same as in the 16-bit-even/32-bit-aligned case. It's all bit-banging, but insofar as the command and address are short compared to a 512-byte sector, it's as fast as ROM.
  11. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @GorgonopsYes, although each device reads out 4 bits at once, you have to specify a byte address to each flash, and then there are four in parallel, so yeah, an address as sent to the SPI flash chips refers to a 32-bit data word. But like you said, it doesn't matter, since we can just write the driver to handle the addressing correctly, plus I believe the API we need to implement concerns itself with 512-byte sectors anyway. My aim with this project is to have a really quick boot time on a Plus, even faster than from floppy or a SCSI disk, and insignificantly slower than the ROMinator-type ROM disks. The MCU approach is very workable, but I wanted to minimize the number of software pieces for this project. More software always means more bugs, whereas it's easier to iron things out with hardware in my opinion. I also wanted to eliminate the need for the Mac to busywait or poll a register in the course of a read operation. (For write operations, the driver must poll the SPI flash to see when the operation is complete, but I believe the time required for that is less than the seek time of a typical SCSI drive, so it's not too bad.) If you're interested, I did use the MCU approach recently on two Apple II cards for which I have just finished the hardware, "Mouserial" and "Library Card." Mouserial implements an Apple II mouse card with a PS/2 mouse interface. There is an AVR microcontroller on the card in conjunction with a CPLD. The CPLD's main function, other than some decoding and generation of select signals, is to implement a few dual-port registers. The AVR runs at 7 MHz, synchronous with the rest of the Apple II, and frequently polls the CPLD's dual-port registers to check if any new commands have been deposited in the command register by the 6502. The AVR interleaves polling the dual-port registers with bit-banging PS/2 such that the registers are polled whenever the AVR must wait in the context of bit-banging PS/2. If there is a new command, the AVR services it and updates the result and status registers in the CPLD. Meanwhile, the 6502 in the Apple II polls the status register to wait for completion of the command. This way is good for low-bandwidth applications, and the implementation of the dual-port registers in the CPLD was made easier by the fact that I could run everything from the same clock. The CPLD always latches write data into the dual-port registers at the end of PHI0, whereas the AVR has an extra wait state and the CPLD makes sure not to write the AVR's data at the same time that the 6502 is reading or writing. (That's sort of a simplification but it provides the gist of it) Library Card interfaces the Apple II to an ESP32-based WiFi/Bluetooth module. The ESP32 has dual cores and can run at 240 MHz, so I did the bus interfacing differently on this one. In the CPLD, I buffered the data bus and part of the address bus to the ESP32, as well as sent it a select signal. Since the ESP32 is fast and has dual cores, it is just barely possible to poll a select signal in software and input/output data just fast enough to satisfy the 6502's timing. The polling loop has to be run all by itself on the second core, with no scheduler or OS getting in the way. That allows any arbitrary interface to be implemented. Honestly, I don't really know what I should be doing with this card in terms of drivers and software, so I thought that this type of busy-waiting implementation would be the most flexible, at the expense of using a whole core of the ESP32. So the MCU approach isn't foreign to me. I just figured the dumber way is best. Also, a lot of people had this criticism of my ARM-based "Maccelerator" proposal, that it was too new, what with the ARM and the emulation and all, not to mention complicated. I wanted to keep this thing as simple as possible.
  12. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @LaPorta Thank you, but there’s no need! I’m pretty sure this hardware is gonna work, and I’ve been sitting on boards and parts for a while. I’ve gotta make the driver, verify the sort of low-level hardware programming in the big chip, and then make the boards. Little additional expense is involved. @GorgonopsOne more thing on the subject of clock signals and timing, there is a somewhat unusual element (some would even say it’s bad practice) to this board insofar as how it generates the clock signal to be sent to the SPI flashes. For read operations, data must be clocked out of the flash sort of in the middle of the read cycle. What I mean is that the 68000 asserts /AS and /LDS/UDS and then that in turn causes the ROMs to be selected. Somehow, as a consequence of the single falling edge of the ROM’s select signal, a clock pulse with a width of 10ns or so must be sent to the flash. This is generated by a little RC network in conjunction with the CPLD. The RC network is carefully chosen to meet the minimum pulse width spec of the flash as well as the maximum rise time spec of the CPLD. The need for this self-timed circuit is another consequence of not having the clock signal at the ROM socket, or else I’d have to have a faster oscillator always running on the board, and synchronize the inputs. It’s not clear that such a design would fit in the CPLD. 128 macrocells sounds like a lot, but there are fan-in limitations so a bus-oriented design rarely achieves full macrocell utilization in my experience compared to some random logic-type functions.
  13. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    @Gorgonops Yes, there is a good reason to use SPI flash instead of an SD card. The goal was to make the fastest disk possible. If I want to move 16 bits off of an SD card, I need to have a clock going faster than the CPU transfer rate to serialize the data, plus more macrocells and routing resources in the CPLD to buffer the data. And since no clock signal is sent to the ROM socket, I’d have to have an even faster clock on the card and then synchronize the inputs coming from the Mac. So the SPI flash is easier since you can reasonably put 4 and work them all in parallel to make a 16-but port, at the expense of a smaller capacity and the need to wear-level So the aim is to bit-bang but to be able to read data at maximum speed once the proper bits have been twiddled to submit the command and address. This struck me as the easiest way to do that.
  14. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    I will proceed more quickly then since there is interest! Hopefully someone with some experience in driver development for the classic Mac OS can come along. I've read Inside Macintosh, but, unless I missed something, there isn't much about how to install a new driver in the system, though there is a lot about what kind of calls can be made to a disk driver. Also, what kind of development environment is best? I am not sure if I should be trying to develop the driver in Mini vMac or if I should go the unix route and build it in Linux/OS X with a crosscompiler. Does anyone have any experience with this? @LaPorta, it's sort of like a ROM disk but it's also writable, so that makes it an SSD. Sorry if my first post was a little unclear or technobabbley, sometimes I get a little too deep into this stuff. Since Mac Plus doesn't have the capability for an internal hard disk, I wanted to make a fast internal disk that would allow a Plus to boot up an install System 6 with lots of apps and games and stuff. A ROM disk is okay but it would be even better to be able to change the disk from the Finder in the normal way. @Byrd I eyeballed it and thought it would work in a Macintosh SE, but unfortunately the SE has its ROM sockets slightly further apart than the Plus, something like 0.025" further from each other, so a new board would be required to for it to fit properly in an SE. But it's of course doable. The 128k and 512k have a different ROM spacing too, but that's not the biggest problem. The difficult thing is that their RAM is so limited. The driver I had planned needs to store a total of 256 kB of data. Most Pluses have 4 MB of RAM so that's not too bad in exchange for such a fast boot disk, but obviously the earlier Macs can't do it. @maceffects Yes, you and I talked as well. I was going to do a quick board for you to do the requisite address mapping to access the LC PDS card properly in an SE/30, but it sort of slipped my mind as other things came up. You guys should skip right to making a board. PCBs are cheap these days, especially if visual quality isn't critical, as is the case with a prototype. Many PCB vendors will sell you 10 boards of the size you need for $10, then there's shipping which might even be 10-15 more, but hey, if your design works, you have a working, reproducible prototype really easily. I never spend much time in the prototyping stage. Instead I read the manuals and study the existing products that are similar to my design to verify that I'm on the right track. And if your design is wrong, just cut and jumper to make it work, then change that in the PCB and spend another $20 to get the board remade. It's so much easier than wire-wrapping or whatever. If you design a PDS adapter board, I'll check it over and include your it in my next board fabrication order. My plate is really full so I can't really take it on. I just announced a five new Apple II cards on AppleFritter (not much traction over there though), so I've gotta work on finishing those.
  15. Hi 68kMLA, Maybe some people here remember my ARM-based "Maccelerator" proposal from a few years ago. I have cost-reduced the BOM for that project significantly and plan to get the hardware released soon, but that's not for today. Since the Maccelerator proposal, I have been working with a friend of mine, Garrett Fellers, and we have been selling an Apple IIGS memory expansion under the Garrett's Workshop brand. People seem really pleased with that card, so we are trying to get some more of my designs out there. I have a ton of vintage product designs in the backlog which I really wanna release. My post today is about one of them, which we call ROMBUS (or GW4101). It's a 64 MB flash disk interface for Macintosh Plus, replacing its two socketed DIP ROM chips: The original inspiration for the project was Big Mess O' Wires' Mac ROMinator. When I heard it was being discontinued, I tried to come up with a worthy replacement. ROMBUS implements a 16-bit-wide interface to four SPI flash memory chips. The idea is to get the flash chips into quad read/write mode, in which four bits can be read or written at once from each of four flash memories, thus making a 16-bit interface. ROMBUS interfaces with Mac Plus via the Mac's two ROM sockets. To store a patched toolbox ROM with the flash driver, there are two sockets on ROMBUS which can each accommodate a 512 kilobyte flash ROM, making a total of 1 MB of parallel flash ROM. The Mac Plus has 128 kB of ROM, but can address 256 kB through the sockets, so bank-switching is required to access the total 1 MB capacity. Because the R/W signal is not sent to the ROM socket, writing to the 64 MB serial flash and 1 MB parallel flash is accomplished by bank selection. I have had boards for this project in hand for 6 months or so, and the CPLD programming is done too, save for any tweaks or bug fixes: Actually, this is the second revision (GW4101B). The first revision (GW4101A) is basically electrically identical, so the same driver and CPLD programming will work on both, but the flash memory land patterns are wrong, so the GW4201A one can only accommodate 16 MB serial flash despite the board advertising itself as a "32 MB Disk." I will be releasing the design files for this product soon, under some kind of open-source license, probably GPL, so anyone can make (or sell) their own, or make improvements. We (at Garrett's Workshop) have just finished our SMD assembly line, and we will be selling the card for $40 USD, shipped to the US. Not sure if many will purchase it, since BMOW says his ROMinator was not too popular, but the price strikes me as fair, and I am pleased to have eliminated the need to jumper the R/W signal and the couple of address signals like you have to in order to install the ROMinator. We have 20 of the 64 MB boards, but I want to gauge the interest to see if I oughta order more in preparation for a product launch. Now, what I need help with is the driver. I have looked at the drivers for the ROMinator and BBraun's previous work, but the way to access the flash memory is different, plus there oughta be a wear-leveling scheme to minimize erase time overhead and maintain the endurance of the flash. (I have a fair solution for the wear-leveling but it takes 256 kB of memory for a 64 MB disk.) My hope is that some other skilled members of the community can assist with the driver development, and then the whole thing can be put onto GitHub for others to build themselves, improve, learn from, etc. And of course we will sell the boards for $40 each, which we think is fair. So, does anyone want this? Is it fair to ask for assistance on this when we are trying to make some money on sales of the product? And if so, who can assist a little with the driver development? Just pointing me in the right direction in terms of what development tools to use, environment setup, etc. would be really appreciated. Of course, free hardware will be provided to the top contributors. Looking forward to hearing what everyone thinks.
×