Monday, January 28, 2013

Karateka! and Schematic

I can die happy. After spending most of last night and this evening making small speed refinements to get a Karateka disk image to work, with no success, I tried a different disk image file and... Kiai! I have no explanation why one works and the other doesn't, especially since they both work on Virtual ][. (UPDATE: Karateka only loads from Slot 6, Drive 1; I was trying to load from slot 7) In any event, my program can now transfer 2 disk sectors in a single USB transfer. Just about every disk image I have tried works now. If there is a disk image that doesn't work, there seems to be another copy of it out there that does. Not so different than loading up pirated games on an Apple IIe back in the 80's.

I forgot how fun the original Mario Bros. game is. I definitely need to invest in a color monitor though.
I cleaned up my schematic. I think I could probably reduce the part count a little more, but these ICs are cheap and easy to find. Note that I broke out the write protect signal. With every bit transfered out representing a data bit, I don't have room to multiplex the write protect signal into the SPI stream.  You can also pull this to ground or the Phase 2 signal for write protected or write enabled, respectively.


  1. Hi epooch

    I have come to your blog trying to install an imon LCD into mountain lion.

    I have been trying to do it with the standard LCDproc build, but with no success. I've seen you uploaded in the pass an specific compiler script, for the 15c2 0038 IMON LCD, but the hosting where it was is not working.

    If you could provide it to me, or let me know a way to contact you, it would be great.

  2. Eduardo,
    You need to run the imon helper, I made this to make it easier to maintain, and you do not have to change the LCDproc code.
    imon_helper post
    My email is in the comments of that post. Feel free to contact me.

  3. Are you working on anything now for apple disk emulation? Did this evolve further?

    1. Yes,
      I basically ported it to raspberry pi, but it wasn't always fast enough to process data over USB. Going straight to SPI was next, but I haven't had time to work on it.
      I was going to try SPI on the ESP32 next.
      One of the big issues is that most of the disk code is from MAME, which was rewritten to C++ and now none of the code is independent enough to be removed into another program. It is a tangled web of object dependencies which proved too difficult for me to untangle.
      The biggest benefit of using the newer MAME source would be to get woz image support.