Anyone have a circuit to take the EEPROM offline?
jac_goudsmit
Posts: 418
in Propeller 1
Hi guys,
My L-Star project uses almost all the I/O pins on the Propeller. The only pin I can't use for I/O is pin 29 (SDA on the I2C bus to the EEPROM). I pull it high while I generate output signals on pin 28 (SCL to the EEPROM). This guarantees that the I2C bus never gets a start condition while my Propeller program is running, and it works really well. Obviously the circuit gets a bunch of extra pulses while the Propeller is booting from the EEPROM but that's acceptable.
But I was wondering if anyone has ever designed any circuit to take the EEPROM off the I2C once the Prop has booted up, so that both pins 28 and 29 are available as I/O ports.
I can think of a couple of complex solutions e.g. by using a microcontroller to emulate the EEPROM or boot the Prop via serial port, but I was wondering if anyone already has anything that's known to work.
Thanks in advance!
===Jac
My L-Star project uses almost all the I/O pins on the Propeller. The only pin I can't use for I/O is pin 29 (SDA on the I2C bus to the EEPROM). I pull it high while I generate output signals on pin 28 (SCL to the EEPROM). This guarantees that the I2C bus never gets a start condition while my Propeller program is running, and it works really well. Obviously the circuit gets a bunch of extra pulses while the Propeller is booting from the EEPROM but that's acceptable.
But I was wondering if anyone has ever designed any circuit to take the EEPROM off the I2C once the Prop has booted up, so that both pins 28 and 29 are available as I/O ports.
I can think of a couple of complex solutions e.g. by using a microcontroller to emulate the EEPROM or boot the Prop via serial port, but I was wondering if anyone already has anything that's known to work.
Thanks in advance!
===Jac
Comments
-Phil
http://www.ti.com/lsds/ti/analog/switches-multiplexers/overview.page
Especially for the L-Star 6502 Retro-Project a 555 is basically a must have item.
Enjoy!
Mike
I've thought of the 555 idea and the CMOS switch idea before. I didn't know there were specific two-directional multiplexers, that's a good tip, Andrew.
I'm still leaning towards putting a microcontroller in the circuit. It makes the programming a lot more complicated but it has big advantages. One big disadvantage of the simple "wait until booted then yank the EEPROM off the bus" ideas is that I won't be able to use the additional storage in a 64K EEPROM for other purposes because it would be necessary to reset the Prop to connect the EEPROM back to the bus.
There are PIC chips in a DIP package with a USB interface (I have a few as part of a Microchip USB Development Kit) which would be interesting because if I would use one, I could replace the Prop plug by one of those and make my kit 100% through-hole. The PIC could boot the Prop through the serial port and I'd free up pins 28 and 29. The PS/2 keyboard could be connected to the PIC instead of the Prop, and that would free up one or two more pins. It might even be possible to connect a MicroSD card to the PIC instead of an EEPROM which would make it easy to store the Propeller firmware and other media.
Are there any existing projects that boot a Propeller from a PIC? I know this has been asked before but answers are hard to find on Google because it keeps thinking I'm talking about something else.
===Jac
The boot Prop can then load the "65C02" Prop up over serial and of course you can easily add microSD as some kind of file server over serial.
And a whole lot of additional processing power to deal with all those additional I/O pins.
Are any of your designs with PIC chips open-source? I'd like to have a look!
Yes, I agree those PICs don't seem to have a lot of headroom for complicated firmware (I haven't done a lot of work with them). The biggest portion of the firmware is probably taken up with USB library code. But I figure the largest chips may have enough space to either boot a Prop through a serial port, or initialize an EEPROM that's shared with the Prop, while the Prop is held in reset. Converting the PS/2 protocol to a one or two pin serial protocol (or I2C) once the Prop is running is probably also not too hard for a PIC, and it might also be interesting to translate I2C (from the Prop) to SPI (to e.g. a MicroSD card).
I agree. And there are lots of other things to do and I don't have much spare time... I'm just throwing it up in the air to see what sticks, and I'm glad to see you guys think along.
I don't think I want to add a Propeller to the main board. It would get too big and an extra Propeller is overkill for most projects that users might be interested in. I do think it would be interesting to have a second Prop on an expansion board; that Prop would be connected to the data bus and a limited number of address bus pins (say A0..A7). The first Prop would run in sync with the second and the first Prop could do the partial address decoding for the second one, and let it know when it needs to enable which virtual I/O device.
Even if I wouldn't already have P28 in use as clock output to the 65C02 (so I have to halt the 65C02 to use the I2C bus), I don't think that would be an option. I2C is just too slow to keep up with most I/O devices that I would want to have on a 1MHz 65C02. The only time when it's acceptable is if I want to use it for mass storage, when the 65C02 has to wait for data to arrive or be sent anyway.
For a massive number of extra I/O pins, the idea of a second Prop is certainly in my mind. But I've been thinking I could also put an ATmega 1284 on an expansion board instead of the secondary Propeller, and connect it in a similar fashion as I mentioned above: 8 bits to the data bus and 8 bits to the low address bus, and a few bits to let the Prop control the software on the ATMega. Those 1284's have 32 I/O pins, they don't need an external EEPROM, they have native UART/I2C/SPI and ADCs/DACs, and they're available in DIP 40.
===Jac
-Phil
Ha! Good one! I didn't think of that. Yes I could do that, but then I wouldn't be able to run the 6502 clock at slower speeds or stop the clock to step through code. I could use an external PLL or something but I think that goes a little too far. I'll keep the idea in mind for future projects though.
True. But I would think that's cheating
The main chip in the project is (supposed to be) the 65C02, and the Propeller takes care of replacing video hardware, memory, serial communication etc. Emulating the 6502 with the Propeller is probably possible (though I'm not sure if I could do it in a single cog) but it would take the main chip of the project away. Might as well use an emulator like VICE or MESS or something.
I could use an FPGA and emulate the Propeller as well as the 6502. Or just emulate the 6502 and then add the emulation of other hardware in Verilog or VHDL. All of that has been done before and I would also call that cheating.
There are many ways to skin a cat, as they say. But the purpose of my project is to combine a real 65C02 with a modern microcontroller and do some digital electronic magic tricks that are easy to understand and help beginning electronics / computer / software engineers learn about how computers work at the lowest level. They don't need to learn any hardware definition languages, they don't need exotic hardware such as an EPROM burner or a JTAG or ISP interface. All they need is a kit with a soldering iron (or a couple of bucks and I'll solder it together) with a Prop plug and a computer that has USB and can run the PropIDE. All they have to understand to run e.g. Apple 1 software is how to download the appropriate project into the Propeller. All they have to understand to emulate other hardware is how to program the Propeller so it bitbangs the bus fast enough to keep up.
I'm reluctant to even add a second microcontroller because it's really too distracting from the educational value of the rest of the system; if I ever do, I'll probably make it run the same firmware for every project. It's not too hard to explain how a Propeller sits on the address bus and data bus of the 6502 to make it jump through hoops without even needing a ROM or RAM chip, but it's a lot harder to explain why the Prop has a face-hugging PIC on it just to make it boot and to make it talk to the PC and save pins on the Prop.
===Jac
How about.... using a data latch (574) to latch 8 msb address lines from the pins used for address lsbits (or even data pins I suppose), (i.e. latch A8-A15 from A0-A7) this should free up 7 pins as one would be needed to latch the data. As I vaguely recall the 6502 bus is only active when the phi clock line is high (or low-doesn't matter). During the inactive phase there's plenty of time at the speed the 6502 runs to clock the msbits from the lsbits.
I suppose you could save more by latching ALL 16 address lines from the data pins using two latches and two pins for latch clocks, freeing up 14 pins!!! (colour vga? and more). This would of course slow the maximum run speed down, but if I recall the 6502 only ran at 1 or 2 MHz tops, and at the props 20Meg instructions/sec that should be doable?
On second thoughts a daft idea - back to my knitting!!!!!!
Dave
At the risk of getting in deeper embarrassment- In the above I was thinking of latching the props address pins when I SHOULD have been thinking of latching the 6502's address pins and then reading eight pins (bits) at a time and recombining in software. This could be done by not latching but just using tri state buffers 244/245 and use their oe's to select hi/lo address lines. Use 1 pin with inverter to oe lines to save 7 pins or 2 pins no inverter to save 6 pins
Dave- exiting rapidly.
Before I made L-Star, I made Propeddle and unless I misunderstand what you're saying, it did pretty much what you describe: It also had the data bus on P0..P7 but it also used two 74HC244's to put the address bus on P0.P15, and a 74HC574 to control the 65C02 (~IRQ, ~NMI, RDY, SO, ~RESET from P8..P15. From a hardware point of view, I think it was pretty clever (even if I do say so myself) but it was a disaster from the software point of view.
It needed a separate cog to switch the 244's on and off to sample the address bus, and to latch the 574 with the output signals. That meant that the address bus was only available to the helper cogs (the cogs that emulate hardware on the 6502 bus) during a couple of clock cycles, which made it extremely difficult to run the 65C02 at 1MHz. Pretty much all I/O emulating cog programs need to access hub memory for one reason or another, and that made it a real challenge to get the timing right. I was even forced to start cogs in a predetermined order to make things work: When you only have 80 Propeller cycles to do your work (1 microsecond when the 6502 is running at 1MHz), a 23 cycle penalty of a hub instruction is very likely to make you late on the next loop. And if the address is only available during 8 or 12 Prop cycles, that is a real problem.
So, with L-Star I got rid of all that glue logic and made the hardware simpler but required some sacrifices elsewhere; for example L-Star can only do monochrome 1-pin video, and if you want to use the RAM chip it also has to use the 1-pin PS/2 keyboard driver. That's good enough for an Apple-1 or Superboard emulator and probably many other types of 6502 hardware that didn't need interrupts and other fancy stuff. But I'll have to do some magic if I ever want to implement a PET/CBM emulator because it needs a 60Hz or 50Hz clock interrupt (NMI). I can do it by connecting the serial TXD output (P31 if I'm not mistaken) to the NMI pin but without the Propeller serial port it will be difficult to download programs to run on the emulated machine. Hence this forum thread
===Jac
(PS: Propeddle was based on a design by Dennis Ferron, who in 2009 got an honorable mention in a Parallax contest, doing something similar, but he had no latches and three (not two) 74*244s: two for the address bus and one for the data bus. All the messing around with the bits and the enabling of 244's cost a lot of time and I could only ever make it run at about 100kHz instead of 1MHz. That's cool for a toy but not good enough if you want to emulate real 6502 computers)