Jump to content

ZaneKaminski

6502
  • Content Count

    160
  • Joined

  • Last visited

1 Follower

About ZaneKaminski

Recent Profile Visitors

401 profile views
  1. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    I've updated the spec to fix a few mistakes, and I've also added some sample code to operate the ROMBUS from the Mac, which I'll reproduce below: ROMBUS Spec.pdf #define SIGR_WR ((short*)0x41FFE0) #define CSR_WR ((short*)0x41FFD8) #define CSR_RD ((short*)0x41FFD0) #define RXR_RD ((short*)0x41FFD2) #define RXR_RD_SH8 ((short*)0x41FFD4) #define TXR_WR ((short*)0x41FFDA) #define TXR_WR_SH8 ((short*)0x41FFDC) void rbus_enable { *SIGR_WR = 0xC1AD; } void rbus_disable { *SIGR_WR = 0x0000; } void spi_select() { *CSR_WR = 0x8000; } void spi_deselect() { *CSR_WR = 0x0000; } char spi_transfer8(char x) { *TXR_WR_SH8 = x; return *RXR_RD; } char spi_transfer8_slow(char x) { char ret; int i; for (i = 0; i < 8; i++) { // Shift MISO into return value ret <<= 1; ret |= (*CSR_RD >> 13) & 1; // Pulse clock hi then lo *CSR_WR = 0xC000; *CSR_WR = 0x8000; // Clock out MOSI after clock goes lo *TXR_WR = (x << (8 + i)) & 0x8000; } return ret; } char delay_100us() { __asm__ __volatile__ ( " move.l #100, %%d0 \n\t" "1: subq #1, %%d0 \n\t" " bne 1b \n\t" : /* out */ : /* in */ : "d0" /* clobbered */); } This code is designed to provide the HAL layer for Elm-ChaN's SD/MMC library, making it easy to integrate that open-source, well-tested code into a future ROMBUS driver. Edit: Also the boards for Macintosh Plus and Macintosh 512/128 are finished: We will be sending these to production in a few weeks once we release the 2MB and 8MB Mac II ROM SIMMs.
  2. There's some tolerance so I think it'll work okay. One danger with tinning the contacts is that gold doesn't corrode and makes better electrical contact than solder and other metals. For example, it takes some force to get an accurate resistance measurement using nickel-plated multimeter probes, but almost no force is required when using gold-plated probes. So I think we're best off with just the gold pads.
  3. There's one bug I'm aware of which I have yet to squash in my driver: System 6-7.1 work but System 7.5 crashes on boot. Once I fix this, I can send out some test units. In the meantime, I have just sent the 8MB SIMM off to production. 1.2mm thickness. Technically SIMMs are supposed to be 1.27mm (0.05 inches exactly) thick but 1.2mm works well enough. The usual thickness of 1.6mm is certainly too thick, I think.
  4. ZaneKaminski

    ROMBUS - 64 MB flash interface for Mac Plus

    Attached is my spec for the ROMBUS controller, in case anyone is interested. I have selected addresses 0x41FFD0-0x41FFE3 for the ROMBUS registers, and have also successfully used a Mac Plus ROM with these bytes overwritten in Mini vMac. I will get back to this project once the ROM SIMM project wraps up. ROMBUS Spec.pdf
  5. ZaneKaminski

    Hastily designed VGA adapter for Mac Plus

    oops, double post
  6. Now that our Mac II ROM SIMM is almost finished, my friend Garrett and I are getting ready to move on to some of our future classic Mac projects. Next on the to-do list is our "ROMBUS" microSD interface for Mac Plus and 512K. One of our Mac Pluses is broken (E0122 SCR is dead), and the other one's flyback isn't doing so well. So I figured that we would ditch the analog boards and run the Mac Plus digital boards mounted to a sheet of plywood. This would make swapping out the ROMBUS during development easier too. It's easy to hook up an ATX PSU to power the board, but without the analog board, how do you get the video out? I considered a few approaches and was going to do something like bbraun's STM32F4-based video interface for the Mac SE. Right before I was gonna go to bed, though, I got an idea for a really simple VGA interface, so I stayed up all night doing a board design and fleshing out the basic details. This was a few weeks ago, and I got the design back out last night to finish it up. Here's a picture of the board: The board solders onto the Mac's 68000 and hooks it up to an old Lattice MACH5 CPLD. The MACH5 outputs the VGA signals directly and controls two 128k x 8 SRAM chips used as framebuffer RAM.   The state machine in the CPLD must shift out one pixel per 25 MHz clock cycle. (25 MHz being the pixel clock for 640x480 VGA.) Since the system has a 16-bit framebuffer data bus width, and the Mac has 1-bit video, the system must read video data from framebuffer RAM every 16 cycles. Therefore, operation of the state machine is divided into "video cycles" consisting of 16 clocks. The 16 states per video cycle are numbered S0-S15. In S0-S11, the system listens for a write to video memory coming from the 68000 and commits it to onboard framebuffer memory. In states S12-S15, the system reads 16 bits from the framebuffer RAM which will be shifted out over the subsequent video cycle. While this video read operation is ongoing, writes coming from the 68000 are held off and are not committed to framebuffer RAM. This holdoff period lasts 160 nanoseconds, but the Mac takes more than 500 nanoseconds to do a memory access, so the VGA interface does not "miss" any writes which occur during this time. Any video write occurring during this time can can just happen in the next S0-S1 states.  That's the gist of it. Unfortunately the video output will suffer from vsync tearing, since the VGA output is not synchronized to the Mac's VBL, but it's good enough to let me use a Mac outside of the case. We're gonna send the board to manufacturing in the next few days, along with the 8MB ROM SIMM and a few other things... hopefully it works! I don't think we can really sell this thing, since you have to solder it on and it has the vsync tearing, but anyone who wants this is welcome to build one, or I would be willing to sell them for the cost of parts to others doing a project on the 128/512/Plus who wanna run the board outside of the case. Source is here: https://github.com/ZaneKaminski/MacPlusVGA I have not yet compiled the verilog, and there are a few oversights in the state machine which need to be worked out... I'll do that soon.
  7. Alright, I think I've got the driver working perfectly now. Only thing left to decide on is, what ROM checksum should I use? Once I put the checksum in, we will be ready to send some 2MB SIMMs out to test before we do the commercial release. Who would like to test? We wanna give several units away to anyone who thinks they can do a thorough job testing. Please let me know if you're interested. 8MB SIMM will be coming soon. I've just gotta finalize the design files and send 'em to fabrication.
  8. Yeah, I consider disabling the RAM test to be a must-have feature. We are also considering doing a software option to enable/disable the RAM test. It can maybe be done, but there seem to be several issues. Turbo040 puts its 128 kB ROM right after the 512 kB stock ROM. This space is currently used to store the disk image in my driver. At the very least, we would need to move the disk image or change how it's being addressed to dodge the memory area that the Turbo040 is using. However, it could be that the Turbo040 selects its own ROM for any access in the ROM space above the 512 kB ROM. If the Turbo040 is uncooperative like that, I don't think it would be possible to have a ROM disk without bank-switching circuitry in the ROM SIMM. So hopefully that's not the case. It's also not quite clear how the Turbo040 patches the ROM. Someone suggested that it patches a JMP/JSR to its own code into the ROM, but I would like to know some more details of how it's done. I can investigate this eventually but I think we will have to pass on implementing it in the first version. The 8MB SIMM can store two 8MB images though, so you can at least toggle the DIP switch to switch between the stock ROM and one with the ROM disk.
  9. Actually, there isn't so much room in the 2MB SIMM for System 7. It can be done, but would 6.0.8 be better on the 2MB and 7.0/7.1 on the 8MB? Here's a picture of the control panel we are developing so far: To accommodate these settings, I'm diverging from the driver lifecycle implemented in the bbraun/BMoW drivers. Their drivers remove the ROM disk drive entry from the system drive queue when not booting from it. I took that approach for granted as the accepted solution but it doesn't really match how other devices work; a floppy drive is not removed from the drive queue when the disk is ejected. Instead, my driver will present the ROM disk as either inserted or ejected at boot, depending on the boot setting. Mounting the ROM disk when booting from a different volume happens in the driver's accRun routine, in which the disk status is changed to "inserted" and a disk insertion event is posted.
  10. I fixed the driver and now it's working well in ROM disk mode. There's still a bit of work to do on the RAM disk function. I basically copied the idea of allocating the RAM disk in accRun from bbraun, but I think that approach is causing problems. I believe my IIsi tries to write to disk before accRun ever happens, and since the RAM disk is not yet allocated, that write cannot be completed. I have a good idea for a different approach which I will implement soon. Great, only a buck each. We can do a programmer for $25-35, I think.
  11. Thanks for the advice. The machine crashed when I did an A9FF trap, so I guess microbug was not initialized, but the experiment was informative enough in that it told me that the Mac was getting to the end of Prime(...). The issue turned out to be that I had forgotten to call the I/O completion routine when returning, thus the read was never completed. Bbraun compiled his driver in CodeWarrior or something, which evidently provides an entry point stub that takes care of this callback. Thus his driver was similarly affected when I compiled it. The fix was easy enough. I just used the entry point code from IM: Devices page 1-29. Now the machine briefly shows a happy Mac before going back to the “disk?” screen. I’m sure I’ll be able to resolve this soon. Yeah, I think we will ship both the 2MB and 8MB SIMMs with System 7 plus as many useful tools/utilities as we can fit. We would but we can’t find enough 64-pin SIMM socket connectors to justify developing a board design for a programmer. If someone can point me to >100 connectors for sale (TE part number 822033-2), I would almost certainly develop a programmer.
  12. Hi everyone, My friend and I recently made a batch of 2MB ROM SIMMs for the SE/30 and Mac II machines. We wanted a few of these ourselves as well as to sell through our little company (price will be $25 incl. domestic US shipping): We have also finished a design for an 8MB ROM SIMM (actually it holds two separate 8MB images) using cheap 3.3V flash (price will be $35): Before we can sell the 2MB SIMMs or try the 8MB SIMMs (or feel pleased about the project haha), I must implement our ROM disk driver, similar to what bbraun and BMoW have done. I've studied examples from IM: Devices as well as bbraun's source and have written a driver which I feel has a good structure. The driver compiles using the Retro68 toolchain and is automatically patched into a base ROM and concatenated with a disk image. Everything seems to be in order, but my IIsi is getting stuck during boot and I am at a loss for how to debug the problem. The boot never completes but the mouse and VBL keep going. I fixed up bbraun's driver to compile with the new toolchain, and it is failing in the exact same way. I suspect a calling convention mismatch or other issue with the build and ROM patch process but I can't pin it down. I have four logic analyzers but three are put away and the one I have been using needs its software reinstalled (big hassle) and a better SCSI upper byte terminator than my handmade one. So in terms of test equipment, I am stuck with just four-channel scopes and a 2+16ch MSO. I would rather not use that stuff anyway. I would like to print some stuff out over the serial port and see if my code is even getting called and how far it gets, but I am not sure how the boot process goes. I don't know if I can use the serial driver when the disk driver's open call and the first prime calls are made. Or is there macsbug in ROM? We would be happy to reward those providing particularly helpful advice with some of our hardware, including the ROM SIMM and also our Apple IIe and IIgs memory expansion cards. Once we finish this project, we will be able to finish the ROMBUS for Mac Plus and 512K, which I consider to be much more interesting. The driver is here: https://github.com/garrettsworkshop/MacIIROMDiskDriver (the ROM with our driver is in bin/rom.bin and bbraun's driver which I have recompiled is in bin/rom_braun.bin) and the KiCAD files for the SIMM are here: https://github.com/garrettsworkshop/MacIIROMSIMM Right now the RAM disk function and "R" key check are commented out, so the Mac should always boot from ROM. Any help would be greatly appreciated!
  13. 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.
  14. 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.
  15. 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.
×