Best Propellor platform - Apple // emulation
ralphw
Posts: 2
I'd like to emulate an Apple //e, which had these features
The expansion bus I can worry about later, but having VGA output at those resolutions would be nice to have.
I'd really like some advice on the best Propeller-based platform to start with. Being able to add external RAM and get the graphics right are the most important features
I'm interested in the Chameleon-AVR (nice that it has a prototyping area), and other low-cost devices like the Parallax C3. I suppose I could use an actual 65c02 CPU, like the Prop-laptop and Vince Briel's Replica 1 projects.
But I'd prefer to add a second propeller chip before I have to scrounge for a long-discontinued processor.
Suggestions?
- 65c02 CPU
- 128K RAM
- 80x24 text and 560x192 graphics
- simple 555-based analog joystick ports
- expansion bus using memory-mapped I/O
The expansion bus I can worry about later, but having VGA output at those resolutions would be nice to have.
I'd really like some advice on the best Propeller-based platform to start with. Being able to add external RAM and get the graphics right are the most important features
I'm interested in the Chameleon-AVR (nice that it has a prototyping area), and other low-cost devices like the Parallax C3. I suppose I could use an actual 65c02 CPU, like the Prop-laptop and Vince Briel's Replica 1 projects.
But I'd prefer to add a second propeller chip before I have to scrounge for a long-discontinued processor.
Suggestions?
Comments
I currently own 3 Apple IIc and would like to use one for such a project. The other, I have already done a lot of work to install one of the Intel mini-ITX MOBOs with the Atom processor running as a Hackintosh but that's for another forum.
I have one of the small composite (green text) apple monitors made for it. I would like to find one of the original LCD monitors for the IIc (Very rare and worth a lot of money).
At this point, I don't know which Propeller board to use. I have a Proto board as well as a Smartboard. I think the Proto bd or a Morpheus bd would be the best for it. I would like to keep the enclosure intack without to many mods so it looks like the real deal from the outside.
It will be great if we can keep this discussion going as I will need a lot of help and will offer as much help with the hardware as I can. I have been an Apple user since the Apple II came out. I have several manuals for the IIe and IIc including schematics for both.
Talk with you later,
Doug
The boards I'm using are here http://smarthome.viviti.com/propeller
The software is a combination of many drivers and bits of code from many people who post here.
Jumping right into some detailed specs, one of the problems with a single prop emulation (and indeed the prop itself) is the way spin and pasm are integrated and end up leaving a significant part of the hub memory unused. Sometimes 14k of 32k ends up wasted. There are ways to recycle this memory but it is not easy. I did it once recycling the keyboard pasm load area and it took days. The reason you want to recycle hub ram is to free up video buffer space, as external ram is not fast enough for video.
So I would suggest look at Morpheus first as that is a two chip solution. Down the track, it ought to be possible to put it all into one propeller like the Nascom and Colour Genie. It will involve a video buffer that is chopped up into several pieces.
Of course there are other solutions mentioned here.
The Apple //c seems to be the best to ultimately emulate as there is effectively no bus to worry about. The only compication is the video and the //c had only a mono monitor.
I threw out a complete Apple //c preproduction unit including all the original disks for everything Apple produced for this. (I kept my presentation plaque from Apple - we were designing products for Apple) <regrets>. However, I have since found a few original disks that were duplicates that did not get thrown out.
I would go with the ][+, because it came with low memory configurations, as low as 4 and 8K. The Apple ROM sets on the ][+ can be minimally configured to just run the monitor, or Applesoft, or the Integer basic.
There are some games and such written for the low memory configurations that would be possible on a single Prop. From there, expand...
Suppose the //e could be done too. I don't think it ended up any less than the //c, with the right ROM sets, and in emulation, there wouldn't be any difference.
Apples can be very significantly expanded, up to and including a Z80 card, capable of CP/M. We probably would have to draw the line somewhere to get started, and there is a ton of stuff that will run on a 48K ][+
The nice thing about the + is the video is well within the Prop capabilities. Text could go to 80 colums with add on cards too. One thing about the high res screen is the funky addressing. Woz saved a chip on that move, making it non-linear. A lookup table for Y coordinate calcs is more or less standard. (wonder if it's actually in the ROM?)
Apple graphics are just a simple frame buffer, mapped to fixed memory addresses, and most importantly, are not keyed to the CPU on a cycle for cycle basis. No screen sync is possible, which makes that part of the emulation easy, and flexible. It's one of the 8 bit machines where locating video on a second prop might make a lot of sense. The addresses are fixed, and there is no need to display every frame. The program running won't know the difference!
Apple video depends on NTSC artifacting for it's color. On the high-resolution screen, 7 bits of every byte are seen on the screen as pixels, with the high bit being a "phase shift" pixel, where the pixel clock was delayed by 1/2 pixel to impact the artifact colors.
This was essentially the first "color cell", where any byte could display 4 colors, two being black and white, the other two either being red / blue, or green / cyan, depending on the state of the high order bit. That's going to take a color lookup at a minimum. Good news is the resolution is low enough to probably make this very possible. A driver that delivers a authentic look is going to be a bit harder. We've got fixed color phase code done already. The high-color driver I wrote in the wiki uses the same kind of artifacting, and would only need to incorporate the phase shift logic.
I don't think Apples were ever capable of PAL color, because of how the video was created.
Apple machines were the ones I learned about artifacting on, and I've done it on every device that could do TV output since.
Too bad the machines with slots are so big. I kind of want to put a Prop in the Apple to do video, and just as a general dev station... CP/M cards were produced that worked that way. One of the slots exposes enough, or maybe even all, bus signals needed for another CPU to take over the machine.
Seriously, Do take a look at the Replica1, it'll give you some inspiration.
Here's the a mod I did to mine. http://www.youtube.com/watch?v=3Y1Ob9Sjhv8
OBC
Darryl's "Hydra NES Pacman Emulator" comes to mind...
http://forums.parallax.com/showthread.php?p=871551
I think it was built from ericball's 6502 emulation, and added a little functionality.
Baggers had started on the Apple ][ TV driver, so you might be able to make use of that as well...
http://forums.parallax.com/showthread.php?t=110159
I have attached the kernel of a VGA driver. It handles the 1bpp to 2bpp mapping along with the MSB color shift and the odd/even byte. It doesn't do adjacent (white) bits between bytes or the funky Y to address calculations. Note: it generates 280 pixels per line, so you might have to fiddle with the PLLA & VSCL to output to a standard VGA.
We modified one machine back then, thought it was a nice curio, then moved on. One of the teachers bought this cool, "hacking the apple" book.
It is possible to get that from one of the end slots. I can't remember if it was slot 0 or 7, but one of those exposed enough signals, and I think the other one exposed enough to control the machine from the card, instead of the onboard 6502. Maybe both did. Gotta read on the Apple.
Back at that time, a few of us were learning to do some graphics and discovered that about the Apple. The Atari and C64 users had references. I think Chris Crawford wrote the early book on bitmap graphics. Checked it out from the University Library once. The title was something like, "Arcade Graphics for the Apple" Not sure, but that's kind of close.
Anyway, there was a chapter in there on low / no flicker draw techniques that would probably be a good Prop single frame buffer reference. It covered a few techniques, such as low frame rates, incremental changes (something I've always called "ripple draw" in my own mind, because the scene is changing over the course of a few frames, trading image tearing or temporal movement errors for flicker), xor, and some other ideas that would reduce the impact of never knowing where the screen was in it's draw cycle.
Apples are timeless as far as the program knows. We had one with a "Zip Chip" in it, that basically just clocked up the 6502, and that I believe had some logic to detect the Disk controller writes. Been a long time. The point was the program would just run faster, with no real reference, unless a user happened to have a RTC card, or one on a card installed.
(now really wanting a Apple ][e)