I'm working on an 1802 core that uses the concept of a "bus" using hub ram where soft peripherals run in other cogs and communicate of that bus. I'm still not sure if I'm going to be able to squeeze it into the available cog memory and available cycles to get the timing right to support color burst /2 timing. I'll keep you updated on progess. C.W.
C.W. Keep up the good work and post progress! The 1802 has both full hard and full soft emulators. There are numerous reasons for integrating the two, creating peripherals in cogs as software.
I was thinking of trying a soft 1802 emulation as well. The approach I was planning on taking was writing an 1802 instruction set interpreter, then using the shared RAM in the Prop to allow access to an 1861 emulation that would basically be a bitmap of 256 bytes of the 1802's memory space. That way there's no worrying about instruction timing on the 1802, as with a real Pixie chip.
I figured the hexadecimal display and keyboard data registers (for an Elf II style system) could also be in shared RAM, and there should be plenty of space left over on the video display to show those values. So at the top of the display we'd have a memory bitmap, with hex representations of the display and keyboard buffer as well as control switch positions below. It may also be possible to do a graphical display of the hex keypad, giving visual feedback of the keypresses on the display if there's enough memory available for that (could be as simple as a 4x4 character matrix with the characters changing color as a keypress is detected on each key.)
Doing a processor emulation doesn't have to be complicated for a processor as simple as the 1802. Basically set up variables for the various registers, a system memory data structure, then write an interpreter that grabs the next instruction from memory (pointed to by the current PC in the 1802), and then call a routine based on what that instruction does. After that comes the interesting bits in deciding how to deal with things in a more efficient way than simply writing a new routine for each opcode, like having one general routine that uses different sources and destinations based on the opcode, or instructions where the program flow can carry over into another instruction's code.
Given the 1802's minimal instruction set, writing general routines that accommodate different source and destination registers, or memory, is probably the way to go.
At any rate, for my own part I'd want to see what sort of memory it's going to take to do that on a prop before getting too deep into planning all the add-ons and peripherals. An emulation of a plain Elf or Elf II with 256 bytes of RAM should be a very doable starter project. It would even be simplified by using Elf-style I/O (physical switches and hex displays or 7, 10, or 14 segment displays with a driver running on a cog.)
That would give you a Membership Card sized Elf with a Quickstart board and a simple circuit on top. It could be either toggle switches or a hex keypad, perhaps selectable through an I/O line (high for hex, low for toggles) and a hex display. There could be select lines for the display type. For example:
$011 Display with integrated logic like a TIL-311 or HP 5082-7340
$010 14-segment CC
$110 14-segment CA
$001 10-segment CC
$101 10-segment CA
$000 7-segment CC
$100 7-segment CA
I'd add video next, though if a "memory expansion" to, say, 1K to 4K were just blindingly easy I'd consider putting in some sort of control to allow selection of memory size first, then doing the video.
On video, I'd start by just writing a program to display a bitmap of the lower 256B of the Elf's memory space. Pure no-conflict DMA! Once that was done, I'd look at selecting the 256B window within the Elf's memory space (presuming the memory expansion were implemented) and possibly adding the other Pixie display modes.
A quick look at I/O lines (ignoring any potential external selects for now):
4 lines: Control switches and input (Run, Load, M/P, In)
8 lines: Keyboard, either type.
8+ lines: Hex display, any type. (Edited to add "+", as 7-segment displays would take 9 lines without external invertor, other displays would take more if they can't be charlieplexed.)
1 line: Q output.
=21 lines.
Assumes that I/O selection is internal to the Prop. This could be reduced by 2 lines if you only support displays with logic, then 4 lines of data and two select lines (to avoid the use of an external invertor.) There are other tricks for reducing the required I/O lines, too, but this layout wouldn't be too bad with something like:
Keyboard: P0..P7
Display: P16..P23
Q: P24
Control Switches and Input: P28-31
That leaves space for Prop-standard NTSC video and an encoded keyboard later, plus other I/O in the usual places. If VGA video is desired, then the Hex displays can be ignored while VGA is active. Adding hardware I/O select lines to the above could use P8-P11 (one line for keyboard type, three for display type.)
Or it may be better to put Q on P11, I've just seen P24 used as an LED output on some Prop servo boards so that's why that line came to mind for Q. Maybe some of you more experienced with Prop projects can give me a read on that.
Then perhaps use only three lines for the selects, or drop the selects and just expect the user will choose the right Spin objects for their hardware at compile time--but part of the idea behind selects is that a Quickstart board could be preloaded with a general-purpose emulator, then a user that isn't necessarily a Prop programmer could add/build a user interface board and tie the select lines the the right rail for their hardware selections. Or a regular Prop user could change out UI boards without having to change the software (one board for the full toggle-switch experience, another with a hex keypad for when their fingers get tired.)
Depends on whether I/O lines are more important to you for later expansion than flexibility on a preprogrammed board, I guess.
Edit: looking at it a second time suggests it might be better to use P0-P7 as the Elf's bus, with different lines as selects. Then assume a display with logic including hex decoding and a register. The keyboard will hide behind resistors, while the display value would be clocked in with a separate select line.
As a first pass I might look at emulating a Membership Board type system on a Quickstart board. The onboard switches and leds would form the keyboard (leds indicate state of switch), with a daughterboard that has a display and control/input switches.
Anyway, always too many ways to skin a cat. I'm going to stop now before I spend too much time talking and not enough implementing.
Boy, this discussion brought back some memories! I used to love the 1802 chip (I still have quite a few of the 1800 series chips!). It was a fun chip to program and use. I bread-boarded several robot controllers using these chips but haven't used one for quite a few years.
The project is moving along very nice.
We nailed down the choice of languages to offer.
One is an emulated Tiny BASIC nearly identical to the Tom Pittman version.
The other "extra" bonus language is bare bones Tiny-C.
Actually, I think this will be a great learning platform.
The expanded Netronics ELF II had 4K memory, Tiny BASIC, ASCII keyboard
and TV with a video modulator. The motherboard had a segment display, LED
and a hex keyboard with push switches.
The emulator can have all these things, including extras like a mouse,
color TV, and extra C-language. The Prop ELF II can be a tiny color game machine.
Of course the original ELF II never had C language
and you won't find many versions of Tiny-C for the prop
- this one is unique and undergoing tailoring for the Prop COSMAC ELF.
I'm still working with the front panel. This seems to be more challenging..
I bought a new printer to finish it. But the spacing has changed again!
I'll continue working on it...
The Prop ELF II will be a binary version, not hex, so we can have more fun with toggle switches.
It is also reminiscent a little of the Altair.
... It would be tricky to get hold of a cassette recorder now (and having to implement a modem of some sorts), ...
Believe it or not you can still get cassette player/recorders from a variety of sources. And some have a USB interface so that you can 'rip' your old tapes.
Comments
C.W. Keep up the good work and post progress! The 1802 has both full hard and full soft emulators. There are numerous reasons for integrating the two, creating peripherals in cogs as software.
The emulator section was just updated and now includes Lee Hart's "the Card" 1802 hardware emulator. Lots of ideas there.
http://humanoidolabs.blogspot.com/2012/03/propeller-elf-ii.html
I figured the hexadecimal display and keyboard data registers (for an Elf II style system) could also be in shared RAM, and there should be plenty of space left over on the video display to show those values. So at the top of the display we'd have a memory bitmap, with hex representations of the display and keyboard buffer as well as control switch positions below. It may also be possible to do a graphical display of the hex keypad, giving visual feedback of the keypresses on the display if there's enough memory available for that (could be as simple as a 4x4 character matrix with the characters changing color as a keypress is detected on each key.)
Doing a processor emulation doesn't have to be complicated for a processor as simple as the 1802. Basically set up variables for the various registers, a system memory data structure, then write an interpreter that grabs the next instruction from memory (pointed to by the current PC in the 1802), and then call a routine based on what that instruction does. After that comes the interesting bits in deciding how to deal with things in a more efficient way than simply writing a new routine for each opcode, like having one general routine that uses different sources and destinations based on the opcode, or instructions where the program flow can carry over into another instruction's code.
Given the 1802's minimal instruction set, writing general routines that accommodate different source and destination registers, or memory, is probably the way to go.
At any rate, for my own part I'd want to see what sort of memory it's going to take to do that on a prop before getting too deep into planning all the add-ons and peripherals. An emulation of a plain Elf or Elf II with 256 bytes of RAM should be a very doable starter project. It would even be simplified by using Elf-style I/O (physical switches and hex displays or 7, 10, or 14 segment displays with a driver running on a cog.)
That would give you a Membership Card sized Elf with a Quickstart board and a simple circuit on top. It could be either toggle switches or a hex keypad, perhaps selectable through an I/O line (high for hex, low for toggles) and a hex display. There could be select lines for the display type. For example:
$011 Display with integrated logic like a TIL-311 or HP 5082-7340
$010 14-segment CC
$110 14-segment CA
$001 10-segment CC
$101 10-segment CA
$000 7-segment CC
$100 7-segment CA
I'd add video next, though if a "memory expansion" to, say, 1K to 4K were just blindingly easy I'd consider putting in some sort of control to allow selection of memory size first, then doing the video.
On video, I'd start by just writing a program to display a bitmap of the lower 256B of the Elf's memory space. Pure no-conflict DMA!
A quick look at I/O lines (ignoring any potential external selects for now):
4 lines: Control switches and input (Run, Load, M/P, In)
8 lines: Keyboard, either type.
8+ lines: Hex display, any type. (Edited to add "+", as 7-segment displays would take 9 lines without external invertor, other displays would take more if they can't be charlieplexed.)
1 line: Q output.
=21 lines.
Assumes that I/O selection is internal to the Prop. This could be reduced by 2 lines if you only support displays with logic, then 4 lines of data and two select lines (to avoid the use of an external invertor.) There are other tricks for reducing the required I/O lines, too, but this layout wouldn't be too bad with something like:
Keyboard: P0..P7
Display: P16..P23
Q: P24
Control Switches and Input: P28-31
That leaves space for Prop-standard NTSC video and an encoded keyboard later, plus other I/O in the usual places. If VGA video is desired, then the Hex displays can be ignored while VGA is active. Adding hardware I/O select lines to the above could use P8-P11 (one line for keyboard type, three for display type.)
Or it may be better to put Q on P11, I've just seen P24 used as an LED output on some Prop servo boards so that's why that line came to mind for Q. Maybe some of you more experienced with Prop projects can give me a read on that.
Then perhaps use only three lines for the selects, or drop the selects and just expect the user will choose the right Spin objects for their hardware at compile time--but part of the idea behind selects is that a Quickstart board could be preloaded with a general-purpose emulator, then a user that isn't necessarily a Prop programmer could add/build a user interface board and tie the select lines the the right rail for their hardware selections. Or a regular Prop user could change out UI boards without having to change the software (one board for the full toggle-switch experience, another with a hex keypad for when their fingers get tired.)
Depends on whether I/O lines are more important to you for later expansion than flexibility on a preprogrammed board, I guess.
Edit: looking at it a second time suggests it might be better to use P0-P7 as the Elf's bus, with different lines as selects. Then assume a display with logic including hex decoding and a register. The keyboard will hide behind resistors, while the display value would be clocked in with a separate select line.
As a first pass I might look at emulating a Membership Board type system on a Quickstart board. The onboard switches and leds would form the keyboard (leds indicate state of switch), with a daughterboard that has a display and control/input switches.
Anyway, always too many ways to skin a cat. I'm going to stop now before I spend too much time talking and not enough implementing.
Bob
http://humanoidolabs.blogspot.tw/2012/03/propeller-elf-ii.html
A new Lab is being set up for its development and a choice
is now made for simulation of the original Tom Pittman's
Tiny BASIC.
Has anyone updated their Propeller 1802 projects?
This is a COSMAC ELF Emulator, hardware and software, built with a Propeller chip.
http://humanoidolabs.blogspot.tw/2012/03/propeller-elf-ii.html
The project is moving along very nice.
We nailed down the choice of languages to offer.
One is an emulated Tiny BASIC nearly identical to the Tom Pittman version.
The other "extra" bonus language is bare bones Tiny-C.
Actually, I think this will be a great learning platform.
The expanded Netronics ELF II had 4K memory, Tiny BASIC, ASCII keyboard
and TV with a video modulator. The motherboard had a segment display, LED
and a hex keyboard with push switches.
The emulator can have all these things, including extras like a mouse,
color TV, and extra C-language. The Prop ELF II can be a tiny color game machine.
Of course the original ELF II never had C language
and you won't find many versions of Tiny-C for the prop
- this one is unique and undergoing tailoring for the Prop COSMAC ELF.
I'm still working with the front panel. This seems to be more challenging..
I bought a new printer to finish it. But the spacing has changed again!
I'll continue working on it...
The Prop ELF II will be a binary version, not hex, so we can have more fun with toggle switches.
It is also reminiscent a little of the Altair.