OSI emulation: in APR 2017 post indicated would be adding use of serial port to PC.  Still planning to do so? :-)

Is there any way to store programs in the C1P mode? The tinkering I've done before always had the serial port for a terminal and to allow save / load pretty much like the original. (I owned a C1P--good times... I traded it in for a C4P-MF which I still have but haven't powered on in about 30 years.)

Hi Jim! I've been on vacation so my memory is a little vague on the details about the C1P emulation. I think the current version of the firmware lets you use the serial port of the prop plug to enter keystrokes but I'm not sure. The ACIA (which would be used to store programs on cassette with the original hardware) is not emulated at this time, I'm still working on that.

I've looked through the Propeller code, but have to admit it is mostly greek to me. I honestly can't remember ever coming across anything that directly addressed the ACIA other than the I/O routines in the ROM. The one exception was when someone would try to change to baud rate, but that was usually from the command line and only if you had a serial printer. (Which not many of us did.)

On the C4P, I had a serial printer and also a KC audio take interface I could go back and forth between so I could salvage all my C1P cassettes.

I've been tinkering with OSI BASIC in 64tass and running in SYMON, but would like to move it to actual hardware. The thing I know I don't want to recreate is the member mapped video hardware which is one of the cool things about your project.

(I can't reply to your reply to my reply so I'm replying here)

There is no code in Github yet to emulate the ACIA, it's on my system at home and in a very early stage. Basically, it will be a new module similar to the A1PIA.spin module in the Apple 1 emulators. A Propeller cog will detect reads and writes to the ACIA addresses in 6502 space, and will communicate with another module that talks to the PC via the serial port.

I had a look at the current state of the OSI emulator and I see now that I remembered it wrong: at this time (April 2017) the OSI emulation doesn't use the serial port to the PC at all. I apologize if I got your hopes up, but it's purely a software issue: it can definitely be done, and it will be.

I'm sorry the SPIN code is difficult to read. Spin is an obscure language that's specific to the Propeller. I intend to use C and C++ for future projects but when I started on this, the GCC compiler for the Propeller wasn't stable enough to do that yet. There's no way to avoid Assembly because it's the only way to make some things cycle-accurate, but rewriting the SPIN parts in C should make things easier to understand for everyone.

If you're interested, you might learn something from the tutorials at https://github.com/jacgoudsmit/L-Star/tree/master/Software/SimpleIDE. The first 3 demos implement an Apple 1 emulator in C. Because there's no Assembly involved, it can't make the 65C02 run at 1MHz (the C compiler optimizer isn't smart enough to make it run fast enough), but in principle it works the same as the other Apple 1 projects.

I intend to add more demos and write web pages about them, but I've had very little time for the project lately because I've been busy at work and then went on vacation. I intend to write more tutorials e.g. about memory-mapped text video such as the OSI.

By the way, I intend to rewrite the OSI video driver because there were some misunderstandings on how the original OSI video hardware worked: in my emulated video driver (which I originally created for Vince Briel's Superboard III project), the characters outside the "used area" are invisible but I think on the original hardware there were 32 columns and 16 rows of text but the characters outside the "used area" were simply left blank. I also want to make it possible to emulate a later OSI video board that could be switched to 64 columns by poking a value at a certain place.

6502 assembler, I can do. C or C++, not so much. :-)

The original was 32 characters by 32 lines of "video RAM", but only 24x24 was actually displayed. In a lot of assembly code, it was easier to do things in batches of 32 anyway. Everything outside the 24x24 area was left blank by the ROM routines and BASIC.

I think the last design (when they went to the plastic case) allowed you to have 32x16 and there were different modifications available that supported 32x16 (and some other strange values).

The C4P video could support 64 characters per line (with 32 lines--although if I remember right no all lines showed on the screen) and you could "poke" that down to 32. (A lot of the 8x8 pixel characters in the character ROM look better when they are closer to being "chunky" like the 24x24 or the 32x32.

If you get to 64/32 characters by 32 lines AND 24 characters by 24 lines, you would be able to emulate either the C1P or C4P. (There was a separate memory map for color on the C4P. I guess actually it was the C2-4P that was just black and white video. I don't remember seeing much use the 32 character text mode on the C1P--by the time that came out the C1P wasn't as "bleeding edge" as it had been years earlier.)

I definitely understand about being busy and trying to fit things into non-existent "spare time". If I can help on the 6502 / C1P side of things let me know. (I'm happy to buy a kit--I just know that the Propeller side of things is not something I'm likely to unravel.) I haven't looked at the ROMs you're using, but there was also the garbage collection issue in the original 8k BASIC. (There are actually two different bugs--one that hangs the system and one that corrupts strings.) I spend some time running the "definitive" patches for that to ground if you are interested.

I worked for an OSI dealer through part of college and then struck out on my own in the blossoming field of "computer consulting" (which was largely writing software) for a few years until I graduated. Worked on a lot of the Challenger 3 series (which were serial based, included the 6502, 6800, and Z80 processors, could support hard drives, could "time-share" with multiple terminals, and even had some of the first "networking" capabilities in microprocessor based system to allow you to use the hard drive on one C3 system with other systems). For the most part, the C1Ps and C4Ps were reliable machines. Power supply capacitors would go now and then (more in the C4P). Sometimes you had to "reseat" the chips in their sockets.

The C4P (and I think the late model C1Ps) did have some provisions for sound. It was a D/A converter in the C4P. I believe the last builds of the C1P had some type of simple tone generator.

(Once again replying to a reply)

I expect that part of my audience isn't really interested in how the Propeller firmware works or how to create new software-defined computers, they just want to download one project into the Propeller EEPROM and play with the 6502 computer as if it's their old familiar computer. It looks like you are part of that group, and that's perfectly fine. Eventually I want to make it easy for people like you to download various computer emulations without the need to use the Propeller tool or SimpleIDE or anything else. I have some ideas on how to do that, but for now, documentation needs to have the highest priority.

Color video is not possible with L-Star unless you add extra hardware. The Propeller is capable of generating color video, but it would require more than one pin (I'm already using a "cheat" to use a single digital pin for composite monochrome video output). But 64 or 32 columns is easy to do, and will eventually be done. If I get a lot of feedback from people like you who would like to see it, it will move up on the priority list :-)

The bugs in Microsoft BASIC are widely known and have been fixed. I don't know if the ROM image in the L-Star repository on Github has the fixes, but if not, it's easy to build the project with a different ROM file (just change the file name in the OSI.spin module). Similarly, replacing the OSI monitor by SYMON is trivial too.

I've also done a project called #KimStar where I mapped the Apple 1 PIA chip emulator and the WOZ mon into the memory of a MicroKim computer to find out what was wrong with its hardware. I suppose it would be possible to do something similar with the OSI emulator so that you could call SYS <number> to start the WOZ mon and use the serial port of the Propeller to download programs to the OSI RAM memory. 

There are many possibilities of solving the problem of getting software and data into the memory of an emulated computer, but of course it will be necessary to understand the Propeller, the 6502 and the L-Star circuit to do that. I really want to make it possible for everyone to do that but it will take a lot of documentation and therefore a lot of time. Thanks for bearing with me!

I've been reading your various posts and a bit about the Propeller.

Actually, I like your idea of a "bus-based" solution although I may be viewing it differently than you describe.

It seems like you run out of I/O pins long before you run out of horsepower.

And if you look at a lot of what builders tend to find challenging it is around the glue logic and the video. Well, those and storage--but if we wanted easy storage we'd tinker with CP/M instead of the 6502... :-)

A "motherboard" similar to what you have with four to six "expansion slots" would let you take address, data, and clock to those slots. Then you could build a "standalone" daughter card for (using an example) video. Now you just have to 1) emulate video RAM and 2) handle the video output. You could have one Propeller dedicated to those tasks. (Which might mean being able to use VGA even if you emulate lower resolutions so everyone doesn't have to track down another monitor or implement color.)

Part of the config for the Propeller on that card could include things like the font, the memory address (so it could do it's own address decoding, removing the need for any glue logic), the output format, etc..

There could be other cards for the keyboard, ACIA/UART, maybe audio, and who knows what else.

With some I/O freed up for the Propeller on the "motherboard", you could do two chip enable lines--one for RAM and one for ROM. Then if you had 64 kbyte chips, you could map RAM and ROM however you wanted. (Or carve out chunks that would do nothing with the expectation that the Propeller on a daughter card would handle that address range.)

And I do like the concept of mapping part of the "ROM" into the Propeller so you can experiment with new code by loading it there instead of actually burning it into ROM. (Or maybe you just have 64K of ram, load some of it with ROM content, and let the propeller handle the R/W line so those portions are never written to by the 6502.)

One thing doing address decoding down to the byte would do is open up some space. Using the C1P as an example, the ACIA was only decoded down to A10 (I think) so it has 128 bytes tied up. But it really only uses two bytes. (You know address decoding but I'll throw it in for completeness--that means that to the CPU that look like those two bytes are repeated 64 times.)

With byte level address decoding I could now populate that area with (making up a somewhat sane number) two, three, or four "virtual" ACIAs. Or I could set aside 64 bytes as RAM for the monitor to use so I don't eat up so much Page Zero space. Bottom line is that I could remain fundamentally "compatible" while adding new features and functions "in the cracks" of the old memory map.

And, in theory, I could load the Propellers with different code and change from a C1P to a PET to an Apple ][. All with an architecture that makes "glue logic" obsolete--and that is the pain point for a lot of people looking at building their own computer from scratch even if it isn't rocket science.

I'm at the Hackaday Super Conference this weekend! If you want to see L-Star, ask me! I'm wearing a badge with "Jac" on it.

I would have given a presentation or a workshop but the project wasn't done yet (I'm expecting the first production PCB's tomorrow). Maybe next year!

Thanks. That's right. It was exciting to get a real 6502 chip to do something. Plus it's a pretty cost effective Apple 1. I will try out the resistor fix for the TV.

Great project. I got it working with just the terminal connection. My LCD television did not like the 1-pin tv signal too well.

The diagram in the github readme file is missing information on what to connect to the 6502's VDD and VSS pins. It's pretty obvious I suppose though.

I found that it helps to print out a diagram of the 6502 in the orientation that you will wire it, as well as marking down the orientation of the propeller pins on the propeller project board (in the orientation you'll look at them while wiring).

I used two 3300 ohm resistors. One of the resistors I used for 6502 pins 2,4,6,36, and 38. The other 3300ohm resistor, I used for the tact button on pin 40. I'm not sure if two separate ones were necessary, but it got it working.

Perhaps this pinout I used for my project will be helpful to a newbie trying this.

6502 Pin 1 (VPB) - No Connection
6502 Pin 2 (RDY) - +3300 ohm, resistor signal
6502 Pin 3 (PHI1O) - No Connection
6502 Pin 4 (IRQB) - +3300 ohm, resistor signal
6502 Pin 5 (MLB) - No Connection
6502 Pin 6 (NMIB) - +3300 ohm, resistor signal
6502 Pin 7 (SYNC) - No Connection
6502 Pin 8 (VDD) - +3.3 volts
6502 Pin 9 (A0) - Propeller Pin 8
6502 Pin 10 (A1) - Propeller Pin 9
6502 Pin 11 (A2) - Propeller Pin 10
6502 Pin 12 (A3) - Propeller Pin 11
6502 Pin 13 (A4) - Propeller Pin 12
6502 Pin 14 (A5) - Propeller Pin 13
6502 Pin 15 (A6) - Propeller Pin 14
6502 Pin 16 (A7) - Propeller Pin 15
6502 Pin 17 (A8) - Propeller Pin 16
6502 Pin 18 (A9) - Propeller Pin 17
6502 Pin 19 (A10) - Propeller Pin 18
6502 Pin 20 (A11) - Propeller Pin 19
6502 Pin 21 (VSS) - Ground
6502 Pin 22 (A12) - Propeller Pin 20
6502 Pin 23 (A13) - Propeller Pin 21
6502 Pin 24 (A14) - Propeller Pin 22
6502 Pin 25 (A15) - Propeller Pin 23
6502 Pin 26 (D7) - Propeller Pin 7
6502 Pin 27 (D6) - Propeller Pin 6
6502 Pin 28 (D5) - Propeller Pin 5
6502 Pin 29 (D4) - Propeller Pin 4
6502 Pin 30 (D3) - Propeller Pin 3
6502 Pin 31 (D2) - Propeller Pin 2
6502 Pin 32 (D1) - Propeller Pin 1
6502 Pin 33 (D0) - Propeller Pin 0
6502 Pin 34 (RWB) - Propeller Pin 24
6502 Pin 35 (NC) - No Connection
6502 Pin 36 (BE) - +3300 ohm, resistor signal
6502 Pin 37 (PHI2) - Propeller Pin 28
6502 Pin 38 (SOB) - +3300 ohm, resistor signal
6502 Pin 39 (PHI2) - No Connection
6502 Pin 40 (RESB) - +3300 ohm, resistor signal from tact button (add ground to the line if the button is pressed)

Hi Brett! Sorry, as of today (March 17, 2016), the instructions aren't complete yet, it's been a while since I had time for this. I'm happy to learn that it's not too hard to figure things out anyway.

I'm not surprised your LCD doesn't like the 1-pin video output. It might help to put a 470pF capacitor parallel with the video output, but it depends somewhat on how picky your TV is. An old CRT TV should work just fine.

The reason you need the separate 3300 Ohm resistor on the reset (RESB) line is that if you would tie the reset line together to all the other control inputs (RDY, IRQB, NMIB, BE, SOB), you would pull those lines to ground at the same time as the reset line when you push the reset button. If you would set up a system that requires one of the other lines to be pulled down, you'll have to separate that line onto its own 3300 Ohm resistor too.

The list of connections is correct, however you used physical pin numbers on the WDC 65C02 and logical pin numbers on the Propeller. For those reading along: On a DIP Propeller, logical pins 0..7 are on physical pins 1..8; logical pins 8..15 are on physical pins 13..20; logical pins 16..23 are on physical pins 21..28 and logical pins 24..31 are on physical pins 33..40. SMT packages for the Propeller use different pinouts.

Let me know if you have further questions!