Retro II - An Apple II Compatible 6502 Computer

Jon_ThomassonJon_Thomasson Posts: 44
edited 2020-09-15 - 17:59:59 in Customer Projects
Here is a project I've been working on that has not one, but two Propeller's onboard! I call it "Retro II" (every project should have a name, right?). It's a homebrew 6502 computer that plays Apple II games. The computer also has two 15 pin game ports, two 9 pin Apple II joystick ports, cassette in/out, built in speaker/volume/headphone out, vga, ps/2, sd card, and 8 peripheral slots.

Here is a short overview video of the finished computer: https://youtu.be/tcg8ul2Vst0

I've always had a love for the Apple II. It was the computer we had in our computer labs growing up. My mom was a teacher and somehow she was able to purchase one for our family. I still have a lot of fond memories of that computer, and I really wanted to see if I could recreate it in some way now with more modern hardware.

Some basic design decisions for the project. I wanted it to feel like an 80's era computer, with the big beefy through hole components and the big green PCB. I wanted to have it be a learning tool as well. I didn't want to stick everything in an FPGA, because I wanted my kids to be able to see the individual pieces that make the computer work. It also needed to be made of all off the shelf parts that you can buy today and are still manufactured. It needed to interface with modern keyboards and monitors and storage.

I started with the original Apple II schematic and quickly realized that there were going to be a few hurdles. There were several components like the keyboard encoder, DRAM, and 558 timer that were no longer manufactured. In looking at the timing of the system, everything was really tightly coupled and complicated. The timing for the video signals, keyboard multiplexer, and RAM access were all woven together in a beautiful tapestry by Steve Wozniak. But I wanted to see if I could simplify it a bit. This is where the Propeller got involved!

I initially just used a 1MHz oscillator to drive the clock, later on I wired up one of the Propeller's to generate the clock signal. This enabled me to do some neat things like overclocking/underclocking the computer. I can also stop the clock to pause program execution if I want to debug something. I took out the 24 DRAM chips and replaced them with a single dual port static RAM. I also consolidated the six ROM chips into a single ROM. By using dual port RAM, I was able to hook up the other Propeller to read from the video portions of RAM and draw out the VGA signals without interfering at all with the rest of the computer. After decoupling the timing a bit, there were a few small changes to the address decoding in order to ensure it was reading/writing to RAM at the correct times. In addition to handling the timing for the system clock, Propeller 1 also reads the soft switches and relays that data to the video processing Propeller. It also handles reading from the SD Card, parsing the DOS images, and handling the PS/2 keyboard. The two Propeller's talk to each other via an I2C bus.

The video processing Propeller took quite a bit of time to optimize at least for the hires mode. To get things running initially I created a very simple memory monitor in Spin in order to test out reading/writing to memory. The easiest video mode was of course just the full text mode. Initially I used Mike Christle's VGA display driver with the C64 font. After getting text mode working reasonably well, I started to convert the driver incrementally so that it would work with the original Apple II 7x8 fonts. To do this I used a lookup table that mapped between the 8x8 and 7x8 graphic columns.

The hires video mode probably took the greatest amount of time to really optimize. I made use of the book "Apple II Computer Graphics" by Ken Williams, and Bob and Lisa Kernaghan to understand how the video memory was laid out. The hires memory map for the Apple II divided the screen into three main sections. Each section has 8 rows. Each row was divided into 8x8 boxes. So each of these boxes is made up of 8 bytes. But then the bits are displayed in reverse order and the left most bit isn't displayed at all. So that was fun to figure out. I initially had hires mode programmed in Spin to just get the picture working. Not surprisingly though, Spin was pretty slow at drawing each hires frame (about one frame every 5 seconds!). I slowly started optimizing The Spin code, to where it was drawing 1 frame a second. Then I converted the Spin into PASM, which eventually I was able to achieve 50 frames per second! I figured that I could further optimize the frame rate if I divided up each of the three screen sections and had a separate cog processing each section. But I was pretty happy overall with the finished frame rate. Right now the computer draws the picture in one of seven monochrome colors. The nostalgia for me was for the green display, so that's what I set up initially. I may try to implement the full color graphics eventually. It's a little more complicated with the way the Apple II displays color pixels, and I'm not quite sure that the Propeller would support all the colors with the desired screen resolution.

There are still a few things to nail down with the current system. In order to support some of the peripheral cards I would like to use, I need to wire up the Propeller to generate the Phase 1 clock, which is just the inverted main clock, and the Q3 signal, which seems to be a 2MHz clock. I also discovered that my game port controller buttons need some rewiring to get them to work properly. My +-12V switching supply also needs to be fiddled with some more. It works, but it has a really high current draw initially before the output caps are charged. Other than that, there's four bodge wires on the bottom of the pcb, nothing too major, but something to fix with the next board revision.

I'd really like to thank the Parallax community for giving me the tools needed to get this project working. I've listed a few of the modules I'm using below, along with their author:

I2C Slave/Master module - Chris Gadd
fsrw - Tomas Rokicki and Jonathan Dummer
PS/2 Keyboard Driver - Chip Gracey
Button.spin v 1.00 - Kyle Crane

**Update 9/15/2020** I have color mode working!
5312 x 2988 - 539K
5312 x 2988 - 1M
3264 x 2448 - 1M
4096 x 3072 - 250K
4096 x 3072 - 457K
4096 x 3072 - 1020K
4096 x 3072 - 299K
«13

Comments

  • Wuerfel_21Wuerfel_21 Posts: 886
    edited 2020-08-26 - 22:50:02
    Cool Project! Really love that custom enclosure!

    Graphics wise, you can definitely do color and lots more. If I found the right file (your repo is a bit messy), I see that your video code isn't very efficient, so there's a lot of wiggle room for new features:
    - VRAM access (read_byte) always fully sets up everything from scratch when as far as I can tell, you could just leave the address on the bus and do an "add outa,#$100" in the inner "hires_col" loop to get it to give you the next byte
    - You're using a big bitmap in Hub RAM - the good(tm) way of doing graphics on the propeller is to render in real-time so you only have to buffer a few lines ahead of the video scanout (which of course requires the rendering code to be able to keep up with it). Another option is to do the rendering in-line with the video generation (a bit tricky, especially with VGA)
    - lots of minor "this guy isn't very experienced with PASM"-isms. Just some from the aforementioned read_byte routine:
                            andn    outa, ram_lsb_mask
                            andn    outa, ram_msb_mask
                            andn    outa, ram_a15_mask
    
    Unless the timing of the OUTA write is important, avoid doing multiple operations with constant S. In this case you'd do something like
                            andn    outa, ram_all_mask
                            '' where ram_all_mask is the values of ram_lsb_mask,ram_msb_mask and ram_a15_mask ORd together
    
    It's always faster and smaller that way.
                            shl     ram_a15, #17
                            and     ram_a15, ram_a15_mask
                            andn    outa, ram_a15_mask   'clear first
                            or      outa, ram_a15 
    
    This is a job for MUXC and a constant:
                            test    ram_a15, ram_a15_mask_shr_17 wc
                            muxc    outa, ram_a15_mask
                            '' where ram_a15_mask_shr_17 is the value of ram_a15_mask shifted right by 17
    
                            mov     draw_tmp, ina                      
                            and     draw_tmp, #255        
                            mov     ram_read, draw_tmp
    
    Why the draw_tmp register?
                            mov     ram_read, ina                      
                            and     ram_read, #255      
    
    These are just a some random ones that jumped out at me in that function alone. I'm not trying to be rude or anything, I'm just saying that if you put some work in, you can get a good bit more out of what you got. :wink:

    If you want more questionable wisdom to spew from the fountain that is my keyboard, just ask.
  • Hi @Wuerfel_21 , thanks for the comment! Sorry, I guess I need to organize my repository better. You are correct, that file is not very efficient at all. Here's the driver i'm using for my video routines: https://github.com/jonthomasson/retroii/blob/master/firmware/retroii/hires/video/r2_video.spin I think the file you used was at an early stage of testing.

    I won't claim to be an expert in PASM, thank you for all your advice!
  • Oh yeah, found the wrong file, the current one is a lot better - altough the more structural kinda advice holds true.
  • Jon_ThomassonJon_Thomasson Posts: 44
    edited 2020-08-26 - 23:31:44
    Wuerfel_21 wrote: »
    - You're using a big bitmap in Hub RAM - the good(tm) way of doing graphics on the propeller is to render in real-time so you only have to buffer a few lines ahead of the video scanout (which of course requires the rendering code to be able to keep up with it). Another option is to do the rendering in-line with the video generation (a bit tricky, especially with VGA)

    This is cool. I thought I needed a pixel buffer, but if I don't then that would definitely free up some Hub RAM. Do you have any example code for this technique? Thanks in advance!
  • Wuerfel_21Wuerfel_21 Posts: 886
    edited 2020-08-27 - 14:24:44
    Wuerfel_21 wrote: »
    - You're using a big bitmap in Hub RAM - the good(tm) way of doing graphics on the propeller is to render in real-time so you only have to buffer a few lines ahead of the video scanout (which of course requires the rendering code to be able to keep up with it). Another option is to do the rendering in-line with the video generation (a bit tricky, especially with VGA)

    This is cool. I thought I needed a pixel buffer, but if I don't then that would definitely free up some Hub RAM. Do you have any example code for this technique? Thanks in advance!

    I don't really have a clean example (I think I've seen one somewhere in the depths of the forum...), but you can take a look at my VJET graphics driver to see the line buffer technique in action. It draws filled vector graphics to a composite monitor, so it's very different from what you need, but the important thing to notice is the synchronization between the render cogs (in this case there's usually 3 or 4) and the output cog.
    A simple explanation of how it works:
    - There's an 8 line buffer (in this case, 256 pixels wide at 8bpp), which the output cog just vertically repeats down the screen
    - While doing that, it writes it's Y position to RAM
    - The render cogs update the lines of the buffer that aren't currently being read

    VJET renderer: https://github.com/IRQsome/Spin-Hexagon/blob/master/VJET_v00_rendering.spin

    VJET output: https://github.com/IRQsome/Spin-Hexagon/blob/master/VJET_v00_composite.spin
  • @Wuerfel_21 Thanks again, I'll definitely check that out. Neat looking game by the way!
  • Apple with banana for scale! Love it. Neat project, @Jon_Thomasson!
  • Oh wow. The Apple, a 2Plus was the first of the computers that I worked with. Then it was a 2E. By the time I switched to the PC, I was the "top of the heap" in understanding the way that family of machines did things.

    Whilst working in a computer store in Forest Hills NY, I found that I still remembered the binary squawks that an unhappy Apple would make when there was trouble. And in this case the sound the machine made was for "Help! I've blown my ROM!", to the sounds R2 makes when he would be blasted from the Star Wars films. I so advised the surprised intern and the tech about that. The intern was annoyed, and the tech was pleased.

    Good showing there @Jon_Thomasson that was amazing.
  • mpark wrote: »
    Apple with banana for scale! Love it. Neat project, @Jon_Thomasson!

    Thanks @mpark ! I was thinking of putting an Apple for scale instead, but figured the "banana for scale" meme was more well known.


    And in this case the sound the machine made was for "Help! I've blown my ROM!", to the sounds R2 makes when he would be blasted from the Star Wars films.
    That's a great analogy @Buck Rogers with the R2 sounds. I think I've heard some of those same sounds come out of an Apple as well. Good memories! Working at the computer store sounds like it would have been a fun job.

  • cgraceycgracey Posts: 13,014
    edited 2020-08-28 - 06:06:26
    Really neat, Jon!

    Apple ][ was what I learned on, too, back in 1980. Steve Wozniak really did things well. When I got into the C64, I couldn't figure out what the problem was, but it was just a general lack of quality. It took a long time for me to realize that Wozniak didn't just make the Apple ][, but that he had made it exceedingly well. He set a very high standard that I had taken for granted. The C64 hardware was neat, but its firmware was such a mess. Anyway, the Apple was magical to me.

    I will watch your video now.
  • cgracey wrote: »
    Apple ][ was what I learned on, too, back in 1980. Steve Wozniak really did things well. When I got into the C64, I couldn't figure out what the problem was, but it was just a general lack of quality. It took a long time for me to realize that Wozniak didn't just make the Apple ][, but that he had made it exceedingly well. He set a very high standard that I had taken for granted. The C64 hardware was neat, but its firmware was such a mess. Anyway, the Apple was magical to me.

    Chip, thank you for the kind words! I agree Wozniak really made an amazing computer. That's been part of the fun for me with this project, just getting the opportunity to see how well the original Apple II was engineered. You can really see that he put his passion for engineering into every part of the computer. With the Apple II, Woz wanted people to not only use the computer, but also understand how it worked. Then he added all of those expansion ports to it so people could make it do whatever they wanted it to do. And the whole thing came with not only a user manual, but the schematics and source code! After Woz stopped engineering for Apple it seems like a lot of the openness and simplicity went away.

    Thanks again!

  • cgracey wrote: »
    Apple ][ was what I learned on, too, back in 1980. Steve Wozniak really did things well. When I got into the C64, I couldn't figure out what the problem was, but it was just a general lack of quality. It took a long time for me to realize that Wozniak didn't just make the Apple ][, but that he had made it exceedingly well. He set a very high standard that I had taken for granted. The C64 hardware was neat, but its firmware was such a mess. Anyway, the Apple was magical to me.

    Chip, thank you for the kind words! I agree Wozniak really made an amazing computer. That's been part of the fun for me with this project, just getting the opportunity to see how well the original Apple II was engineered. You can really see that he put his passion for engineering into every part of the computer. With the Apple II, Woz wanted people to not only use the computer, but also understand how it worked. Then he added all of those expansion ports to it so people could make it do whatever they wanted it to do. And the whole thing came with not only a user manual, but the schematics and source code! After Woz stopped engineering for Apple it seems like a lot of the openness and simplicity went away.

    Thanks again!

    Yes, I bought a Mac when it came out and, for a few days, I figured I just wasn't finding the manuals for how to program it. Someone who knew had to explain to me that you must register as a developer to write software for it. I couldn't believe it. It was like a betrayal.

    Steve Wozniak is still very freedom-minded and avoids getting boxed into controlled schemes.

    It's probably occurred to you that you could, if you wanted, realize your entire Apple ][ project in a single P2 with an 8-pin 16MB flash chip. Might be kind of fun. If you are interested in looking into it, I will send you a P2 Eval board, which is all you'd need.
  • cgracey wrote: »
    It's probably occurred to you that you could, if you wanted, realize your entire Apple ][ project in a single P2 with an 8-pin 16MB flash chip. Might be kind of fun. If you are interested in looking into it, I will send you a P2 Eval board, which is all you'd need.

    You know I was thinking it'd be nice to replace the two P1's with a single P2. But it hadn't occurred to me that I could possibly stuff everything into a P2. That would actually be pretty cool. I need to catch up with the P2 development it seems.

    I do have a P2 dev board that I bought back in late 2018 but sadly I haven't done much with it yet. This may be the excuse I need to get the ball rolling. Thanks :smile:

  • Cluso99Cluso99 Posts: 16,573
    edited 2020-08-29 - 00:50:39
    It is absolutely doable in a single P2.

    See my Propeller 2 OS - it's alive! And CPM2.2 is running! thread
    https://forums.parallax.com/discussion/comment/1499300
  • You can sink the 6502 into the P2, like Cluso did with the Z80 to make CPM (if I understand his CMP correctly).
  • Cluso99Cluso99 Posts: 16,573
    edited 2020-08-29 - 04:55:41
    Exactly.
    The P2 emulates the Z80 plus extra code to make the SD card FAT32 files look like CPM disk drives, provide serial interfaces and a few other things.

    We did the same on P1 but because of the limited RAM we needed to add an external SRAM. The P2 has 512KB of hub RAM so no need for external SRAM. On the P1, the Z80 ran about the same speed as a 4MHz Z80. While I have no timing info yet for the Z80 on P2, I am initially expecting 10x performance, and there are other things to do to increase this substantially.

    The 6502 is a much simpler and more regimented instruction set so it will be much easier to do. Of course the specifics of the hardware that Woz did in the Apple will need to be implemented in software but I wouldn't expect too many problems here.

    The one issue on the Apple that I am aware of is the way adjacent pixels on the color screen are used to get alternative colors. I am unsure if this is possible and how it could be done.
  • Cluso99 wrote: »
    Exactly.
    The P2 emulates the Z80 plus extra code to make the SD card FAT32 files look like CPM disk drives, provide serial interfaces and a few other things.

    We did the same on P1 but because of the limited RAM we needed to add an external SRAM. The P2 has 512KB of hub RAM so no need for external SRAM. On the P1, the Z80 ran about the same speed as a 4MHz Z80. While I have no timing info yet for the Z80 on P2, I am initially expecting 10x performance, and there are other things to do to increase this substantially.

    The 6502 is a much simpler and more regimented instruction set so it will be much easier to do. Of course the specifics of the hardware that Woz did in the Apple will need to be implemented in software but I wouldn't expect too many problems here.

    The one issue on the Apple that I am aware of is the way adjacent pixels on the color screen are used to get alternative colors. I am unsure if this is possible and how it could be done.

    Nice work with Propeller 2 OS! That's really impressive. I was reading up on the P2 some more last night, and getting excited about the possibilities.

    You're right about the weird color issues with the Apple II. That's part of why I only implemented the monochrome screen originally. It seems like there must be a way to do it though.
  • Wuerfel_21Wuerfel_21 Posts: 886
    edited 2020-08-29 - 14:49:15
    The obvious way to do the color is to just output the monochrome over composite video :) and the problem solves itself.

    To actually decode the color in software seems somewhat tricky. As far as I can tell, it can be thought of as a simple 2bpp encoding, except bit7 is used to select the palette, which incurs the problem of each byte containing 3 whole pixels and a half-pixel (What happens when a colored pixel is on a palette boundary? Seems like a rare edge-case). (In reality the palette select also shifts the pixels of that byte by a quarter-pixel, but that seems negligible for color mode).

    Here's what I'd do to do the color decoding on P1 - not sure if that'd work properly, don't have experience with apple graphics:
    - read data from video RAM and rearrange such that an original byte pair %A_BCDEFGH,%I_JKLMNOP is written to the internal buffer as a word %AI_JKLMNOPBCDEFGH
    - write the video output code to display a 3 pixel slice and a 4 pixel slice with selected palettes, kinda like this (might be too slow for VGA rates? OTOH this is really low-res.) :
              mov iter,#20
              '' pretend we initialite pixel_ptr here
              
    :xloop
              rdword pixels,pixel_ptr
              add pixel_ptr,#2
              test pixels,bit15 wc
              muxc :wv1,bit9
              mov vscl,vscl_3pixels
    :wv1      waitvid palette0,pixels
              test pixels,bit14 wc
              muxc :wv2,bit9
              shr pixels,#6
              mov vscl,vscl_4pixels
    :wv2      waitvid palette0,pixels 
              djnz iter,#:xloop
    
    '' must be aligned to 2 longs
    palette0 long 1234 ' pretend this is the white-purple-green-black palette
    palette1 long 5678 ' pretend this is the white-blue-orange-black palette
    
  • Wuerfel_21 wrote: »
    To actually decode the color in software seems somewhat tricky. As far as I can tell, it can be thought of as a simple 2bpp encoding, except bit7 is used to select the palette, which incurs the problem of each byte containing 3 whole pixels and a half-pixel (What happens when a colored pixel is on a palette boundary? Seems like a rare edge-case). (In reality the palette select also shifts the pixels of that byte by a quarter-pixel, but that seems negligible for color mode).

    Here's what I'd do to do the color decoding on P1 - not sure if that'd work properly, don't have experience with apple graphics:
    - read data from video RAM and rearrange such that an original byte pair %A_BCDEFGH,%I_JKLMNOP is written to the internal buffer as a word %AI_JKLMNOPBCDEFGH
    - write the video output code to display a 3 pixel slice and a 4 pixel slice with selected palettes, kinda like this (might be too slow for VGA rates? OTOH this is really low-res.) :

    That's a good way of thinking about bit 7. It's just in charge of selecting which palette to display, either black/green/violet/white or black/orange/blue/white. I may load up an emulator later on to see if I can nail down exactly what's going on. Thank you for that code also, that'll give me a great start. Really appreciate it, thank you!
  • potatoheadpotatohead Posts: 10,095
    edited 2020-08-30 - 03:56:48
    There are 7 pixels per byte. Even bits in even bytes artifact to create the same color. Odd bits in odd bytes will create the same color as the even bits in even bytes do.

    Most computers have 8 bits aligned on a color cycle boundary. Even bits are always the same color no matter whether bytes are odd or even.

    The high bit shifts output by a half pixel, resulting in that byte being able to enable display of white, black and either:

    Red / Blue
    Green / Cyan.

    The apple bit patterns repeat every two bytes, not every single byte like pretty much every older computer does.

    Two bytes = 14 pixels, or 7 color pixels depending on whether a color composite display and the color burst are present and enabled.

    There are edge cases: one byte high bit set, next byte not and some bit patterns show additional colors at times.

    For most purposes, treating it like a 2bpp display that repeats color by pixel mapping every two bytes will work.

    Unlike most color displays, a single pixel can have color, where most 2bpp displays feature pixels twice as wide as they are high. This only happens on the Apple when two adjacent even or odd bits are present.

    https://mygaming.co.za/news/wp-content/uploads/2012/03/Prince-of-Persia-Apple-II-screenshot.jpg

    You can see that put to use in this screen shot.

    Here is the color clash and edge cases.

    https://upload.wikimedia.org/wikipedia/commons/thumb/6/6a/Apple_II_high-resolution_graphics_fringe_effects.png/300px-Apple_II_high-resolution_graphics_fringe_effects.png

    If it were me doing Apple HGR screens, I would read words and do color lookups on the pixels. That repeats nicely, meaning only one table needed.

    If the display is 280x192, say 16 colors, apple graphics map to a small 8 color lookup table.

  • Is there any possibility of doing a production run, even a kit? I'll be first in line to order one.

    Will an original Apple disk drive work with this?
  • I think the way to convert those hires bytes into pixels is to lookup one of 256 longs which each have 7 four-bit fields in them. Then, use LUT mode in the streamer to output them.
  • This is the COOLEST! I love it. Apple ][ was my first computer.
  • Wow, thank you everyone! You guys have given me all sorts of cool ideas. This project marks my first foray into writing PASM so bear with me as I'm still learning this stuff. Initially I borrowed someone elses VGA driver, which was great to get me started. But that may have given me some of my misconceptions about what was possible with the Propeller video generator.

    I was thinking that going from monochrome to full color would more than double my needed pixel buffer size. But really this doesn't seem to be the case. Initially I thought that the pixel buffer should have only displayable pixels, so I was taking out the color bit prior to sending it to waitvid. But Wuerfel_21's code opened my eyes a bit. If I understand his code correctly, I can keep that color bit in the buffer, and then use it in my vga driver to switch out the color palette. Then I can control how many pixels are transmitted at a time with vscl which is pretty cool.

    Of course growing up with the green monochrome screen, I was oblivious to all of this. It's both really cool, and super confusing. You can't have just a white pixel by itself. The minimum horizontal spacing to create white is 2 pixels wide which is bizarre. And then the fact that each byte has 3.5 color pixels, so you need 2 bytes in order to get 7 complete pixels. On top of that the edge cases and clashing that @potatohead mentioned. It makes things a bit complicated.

    I really like @potatohead's idea of thinking about it like odd/even bytes. And then supplying a lookup table to translate the pixels into their appropriate colors. I may try something like that.
    cgracey wrote: »
    I think the way to convert those hires bytes into pixels is to lookup one of 256 longs which each have 7 four-bit fields in them. Then, use LUT mode in the streamer to output them.
    @cgracey is that streamer available in the P1, or is it a P2 thing only? That looks like a pretty cool feature.

  • Whit wrote: »
    This is the COOLEST! I love it. Apple ][ was my first computer.

    @Whit Thanks! It's always nice to meet another Apple ][ fan.
  • The_Master wrote: »
    Is there any possibility of doing a production run, even a kit? I'll be first in line to order one.

    Will an original Apple disk drive work with this?

    That would be really cool. There's a few hurdles I'd have to get over though. Legally, there may be a problem if I start distributing the Apple II rom. I'm not a lawyer, so I can't really comment on it. They may not care since it's just a small project, but it still may be an issue.

    The second hurdle would be the price. In order to really knock down the price, I'd need to order a lot of parts in higher quantities. I don't know if there's that much of a demand for this type of thing to warrant that.

    I do have the project open source. So people can make one for themselves if they wanted to. I was also thinking that I could sell the pcb's and then provide links to the bill of materials.

    In theory an original disk drive should work, although I don't have one to test it with. I have a Booti drive that uses an sd card that I want to get working with it. The issue there is that I need to hook up the Propeller to output the phase 1 clock and the Q3 signal still. I'm thinking it shouldn't be too difficult to do that hopefully.

    I still have a few changes to make in the pcb where I had to bodge some wires. I'm honored to see that people think it's a cool project. Thanks!
  • The_Master wrote: »
    Is there any possibility of doing a production run, even a kit? I'll be first in line to order one.

    Will an original Apple disk drive work with this?

    That would be really cool. There's a few hurdles I'd have to get over though. Legally, there may be a problem if I start distributing the Apple II rom. I'm not a lawyer, so I can't really comment on it. They may not care since it's just a small project, but it still may be an issue.

    The second hurdle would be the price. In order to really knock down the price, I'd need to order a lot of parts in higher quantities. I don't know if there's that much of a demand for this type of thing to warrant that.

    I do have the project open source. So people can make one for themselves if they wanted to. I was also thinking that I could sell the pcb's and then provide links to the bill of materials.

    In theory an original disk drive should work, although I don't have one to test it with. I have a Booti drive that uses an sd card that I want to get working with it. The issue there is that I need to hook up the Propeller to output the phase 1 clock and the Q3 signal still. I'm thinking it shouldn't be too difficult to do that hopefully.

    I still have a few changes to make in the pcb where I had to bodge some wires. I'm honored to see that people think it's a cool project. Thanks!
    PCB + BOM sounds good. It's been a while since I've sourced parts for a project and this might be a good opportunity to do it again.

  • Wuerfel_21Wuerfel_21 Posts: 886
    edited 2020-08-31 - 19:55:19
    The_Master wrote: »
    Is there any possibility of doing a production run, even a kit? I'll be first in line to order one.

    Will an original Apple disk drive work with this?

    That would be really cool. There's a few hurdles I'd have to get over though. Legally, there may be a problem if I start distributing the Apple II rom. I'm not a lawyer, so I can't really comment on it. They may not care since it's just a small project, but it still may be an issue.

    The second hurdle would be the price. In order to really knock down the price, I'd need to order a lot of parts in higher quantities. I don't know if there's that much of a demand for this type of thing to warrant that.

    I do have the project open source. So people can make one for themselves if they wanted to. I was also thinking that I could sell the pcb's and then provide links to the bill of materials.

    In theory an original disk drive should work, although I don't have one to test it with. I have a Booti drive that uses an sd card that I want to get working with it. The issue there is that I need to hook up the Propeller to output the phase 1 clock and the Q3 signal still. I'm thinking it shouldn't be too difficult to do that hopefully.

    I still have a few changes to make in the pcb where I had to bodge some wires. I'm honored to see that people think it's a cool project. Thanks!

    Computer emulators generally come with the all relevant ROM images, so my theory is that no one actually cares. Another option would be to use write-protected RAM in place of ROM and somehow load that from the SD card on power-up.
  • cgraceycgracey Posts: 13,014
    edited 2020-09-01 - 00:21:11
    You can direct people to here for the ROM files:

    https://macgui.com/downloads/?file_id=14064

    The P2 has a streamer, but the P1 does not. You could do the whole thing on the P2, no other chip needed. In fact, you could probably emulate EIGHT Apple ]['s concurrently.

    I think you'd need this for each Apple ][:

    48KB RAM
    1 cog, generates video on interrupts via streamer, main code handles emulation
    1 pin for composite video out
    2 pins for USB or PS2 keyboard
    3 pins for joystick?

    That could leave 128K of hub RAM for the Apple ][ ROM and emulator code, plus the top 8 pins free for development. The SPI flash could be shared among all Apple ]['s as a virtual drive, shared via a LOCK. You would just write ONE program to make it all happen.
  • I do like the P2 idea. Having only the P2 on the board would greatly reduce the BOM cost and probably make the board easier to sell/manufacture. Maybe the P2 version could be called the Retro IIe :wink:
Sign In or Register to comment.