Shop OBEX P1 Docs P2 Docs Learn Events
Retrofitting old processors? — Parallax Forums

Retrofitting old processors?

John A. ZoidbergJohn A. Zoidberg Posts: 514
edited 2015-05-09 08:51 in General Discussion
Hey there,

Somewhere in the internet, managed to find some person who placed a Propeller to support an actual 65C02 processor - it looks like a fun job where new and old mix together. I believe the name is Propeddle by Jac Goldsmith, if I'm not mistaken.

I was in the eBay and I bought a few classic processors - the 6502s, Z80s, and the NEC V20s.

Could I use a big, fast microcontroller ( with a lot of pins ) as an address-decoder to support the classic processor like 6502? At the least I do not have to wire up too many latches and buffers on the breadboard.

And I'm reading the datasheet of the access times for read and write - the "soft address-decoder" must be fast enough to decode the addresses.

Hope I'm not really asking a weird question. Yeah, I know there's the Raspberry Pi over on my table - I loved to build my own retro-fitted retro-PC. :)
«1

Comments

  • GadgetmanGadgetman Posts: 2,436
    edited 2015-04-25 03:25
    Address decoder?

    How exactly?
    The 6502 and the Z80 have a 16bit address range, and the V20 is a i8088-compatible CPU.
    Both the 6502 and the Z80 have 'full busses' (none of that 'overlaying the databs on the lower half of the address bus' such as the i8085 does)
    They can directly address 64KB of data, double what the Propeller has of HUB RAM.

    If you were thinking of using the Prop to segment a larger memory into pages that can be swapped in or out of random locations in the address space, that can probably be done faster by using a few latches or an FPGA.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-25 04:41
    A typical use of address decoding is when you want 32K or RAM and you have 16 times 2K RAM chips. Then you need to generate 16 chip select signals, one for each RAM chip, to enable the correct chip for the address being accessed. That might require that you decode 4 upper address bits into 1 of 8 signals for the chip enables.

    Similarly for decoding addresses into chip selects for I/O devices.

    Logically the Prop can do this easily. Can it do it at the speed you want? Not sure.

    It might be a way to go during development. Run the system slower so that the Prop has time to do that work. Then when your design is finalized and stable redo that logic in actual chips.

    I have considered this approach when pondering getting a 68000 chip running with a tube of 2K RAMs that I have lying around. A Prop of course would provide the I/O and video for such a system if I ever get around to building it.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-25 05:58
    Gadgetman wrote: »
    Address decoder?

    How exactly?
    The 6502 and the Z80 have a 16bit address range, and the V20 is a i8088-compatible CPU.
    Both the 6502 and the Z80 have 'full busses' (none of that 'overlaying the databs on the lower half of the address bus' such as the i8085 does)
    They can directly address 64KB of data, double what the Propeller has of HUB RAM.

    If you were thinking of using the Prop to segment a larger memory into pages that can be swapped in or out of random locations in the address space, that can probably be done faster by using a few latches or an FPGA.

    The 6502 and the Z80 are easier to work with due to the address lines being seperate instead of shared.

    However, the V20/i8088 isn't the way, and I have to end up using a very fast microcontroller (like PIC32) to perform the address decoding.

    Or, I would just use the latches like in every examples in the net.
    Heater. wrote: »
    A typical use of address decoding is when you want 32K or RAM and you have 16 times 2K RAM chips. Then you need to generate 16 chip select signals, one for each RAM chip, to enable the correct chip for the address being accessed. That might require that you decode 4 upper address bits into 1 of 8 signals for the chip enables.

    Similarly for decoding addresses into chip selects for I/O devices.

    Logically the Prop can do this easily. Can it do it at the speed you want? Not sure.

    It might be a way to go during development. Run the system slower so that the Prop has time to do that work. Then when your design is finalized and stable redo that logic in actual chips.

    I have considered this approach when pondering getting a 68000 chip running with a tube of 2K RAMs that I have lying around. A Prop of course would provide the I/O and video for such a system if I ever get around to building it.

    I'm trying to run it at 4.77MHz - the original IBM XT speed. I will use a Prop for the video driver too at an instant. :)
  • GadgetmanGadgetman Posts: 2,436
    edited 2015-04-25 07:10
    For the 2KB RAM chips you just get a stack of 3-to-8 decoders(74138) or even some 4-to-16 decoders(74155) if you're not planning any 'weird' stuff such as segmenting or swappable pages.

    Of course, with a MCU such as a Propeller hidden in there, you could have it do all kinds of 'interesting' side jobs...

    Imagine that there's transparent buffers on the busses, next to each memory block, such that the MCU can 'cut it off' from the CPU. The MCU can then update the memory block without the CPU being blocked from the rest of the memory.
    (Maybe loading stuff from a SD-card, or outputting the contents to a file or printer?)

    Most vintage CPUs have a 'decode' clock cycle where they don't do anything on the bus.
    (Well, the Z80 can do DRAM Refresh in that cycle)
    A MCU running at 80MHz should be capable of taking over the bus and updating/reading one or two memory locations in that single 'decode' cycle.

    The IBM XT ran at 4.77MHz becausethat was the easiest frequency below 5MHz to reach with a 14.318MHz crystal.
    (The 14.318MHz crystal is dirt-cheap because of the use in TVs.)
    That's the only reason it ran at that speed...
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-25 07:53
    Gadgetman wrote: »
    For the 2KB RAM chips you just get a stack of 3-to-8 decoders(74138) or even some 4-to-16 decoders(74155) if you're not planning any 'weird' stuff such as segmenting or swappable pages.

    Of course, with a MCU such as a Propeller hidden in there, you could have it do all kinds of 'interesting' side jobs...

    Imagine that there's transparent buffers on the busses, next to each memory block, such that the MCU can 'cut it off' from the CPU. The MCU can then update the memory block without the CPU being blocked from the rest of the memory.
    (Maybe loading stuff from a SD-card, or outputting the contents to a file or printer?)

    Most vintage CPUs have a 'decode' clock cycle where they don't do anything on the bus.
    (Well, the Z80 can do DRAM Refresh in that cycle)
    A MCU running at 80MHz should be capable of taking over the bus and updating/reading one or two memory locations in that single 'decode' cycle.

    The IBM XT ran at 4.77MHz becausethat was the easiest frequency below 5MHz to reach with a 14.318MHz crystal.
    (The 14.318MHz crystal is dirt-cheap because of the use in TVs.)
    That's the only reason it ran at that speed...

    Hello,

    I'm using a much bigger RAM chip - what I have there is a 512Kilobits one, and will only use the 1st 16-bits of the address (A0-A15).

    As I do not have an EEPROM programmer, I'm not even sure if it's feasible to use a RAM instead and an external microcontroller dumps the hex file into the RAM.

    I'm waiting for the vintage processors to come, so I'm still checking the datasheets for more info. :)
  • kwinnkwinn Posts: 8,697
    edited 2015-04-25 10:00
    Hello,

    I'm using a much bigger RAM chip - what I have there is a 512Kilobits one, and will only use the 1st 16-bits of the address (A0-A15).

    As I do not have an EEPROM programmer, I'm not even sure if it's feasible to use a RAM instead and an external microcontroller dumps the hex file into the RAM.

    I'm waiting for the vintage processors to come, so I'm still checking the datasheets for more info. :)

    Using a propeller to load a hex file to ram for another microprocessor to execute or process is feasible and has been done for several vintage micros already. Another option is to use the propeller to emulate the eeprom for booting and execute from ram once the program or operating system is loaded. With careful design the propeller can then be used for some of the I/O interfaces such as serial and sd storage.

    PS, which microprocessor do you want to use first?
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-25 10:06
    kwinn wrote: »
    Using a propeller to load a hex file to ram for another microprocessor to execute or process is feasible and has been done for several vintage micros already. Another option is to use the propeller to emulate the eeprom for booting and execute from ram once the program or operating system is loaded. With careful design the propeller can then be used for some of the I/O interfaces such as serial and sd storage.

    PS, which microprocessor do you want to use first?

    Yeah, this is that plan I'm attempting. It will be messy but I guess it's pretty worthwhile.

    I'll start with the 8088 - I know that processor is very clunky and inelegent, but so far, not much has been attempted to retrofit an 8088 processor. (There's one in the Youtube but the Prop inside is working as a discrete video generator). :)
  • kwinnkwinn Posts: 8,697
    edited 2015-04-25 10:52
    The 8088 is a bit more involved than the older 8 bit chips, but should not be that hard to control with a propeller. The biggest decision to make is probably whether or not you want to use it in maximum mode and if you want to address 1MB of ram. After that you would need to decide how you want the propeller to interact with the 8088.

    BTW is it the original nmos chip or one of the later variants like the V20?
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-25 18:21
    kwinn wrote: »
    The 8088 is a bit more involved than the older 8 bit chips, but should not be that hard to control with a propeller. The biggest decision to make is probably whether or not you want to use it in maximum mode and if you want to address 1MB of ram. After that you would need to decide how you want the propeller to interact with the 8088.

    BTW is it the original nmos chip or one of the later variants like the V20?

    I prefer to start with the minimum mode, and then all the way to maximum mode if I get the first one working.

    The version of the V20 is the low voltage one which is down to 3V so that it'll be easier to interface with modern components (esp Propeller). :)
  • jmgjmg Posts: 15,173
    edited 2015-04-25 18:25
    And I'm reading the datasheet of the access times for read and write - the "soft address-decoder" must be fast enough to decode the addresses.

    This comment answers the question you ask - the crucial detail is SPEED, and software is unlikely to be fast enough (plus will be a pain to debug)
    Better to use a Programmable Logic device, if you want to save latches/decoders for memory.
    You likely need 5V, so that limits the choices a little.
    Atmel ATF1502/1504/1508 are JTAG programmable (use FT2232H/FT2232), and are 5V and of moderate speeds.
    The 1504ASVL/1508ASVL have 3.3 & 5V operating.

    Or, if you have a programmer, the 16V8/22V10 series SPLDs can do simpler logic replacement.
    Could I use a big, fast microcontroller ( with a lot of pins ) as an address-decoder to support the classic processor like 6502? At the least I do not have to wire up too many latches and buffers on the breadboard.
    See above.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-25 18:53
    jmg wrote: »
    This comment answers the question you ask - the crucial detail is SPEED, and software is unlikely to be fast enough (plus will be a pain to debug)
    Better to use a Programmable Logic device, if you want to save latches/decoders for memory.
    You likely need 5V, so that limits the choices a little.
    Atmel ATF1502/1504/1508 are JTAG programmable (use FT2232H/FT2232), and are 5V and of moderate speeds.
    The 1504ASVL/1508ASVL have 3.3 & 5V operating.

    Or, if you have a programmer, the 16V8/22V10 series SPLDs can do simpler logic replacement.


    See above.

    Thanks for the reminder. I'll have to use the discrete latches and the buffers instead.

    And these SPLDs are nice too. I'll give them a try. :)
  • kwinnkwinn Posts: 8,697
    edited 2015-04-25 20:18
    If you want to run at close to full speed you will need to use hardware for address decoding and latching. That could be discrete latches, buffers, and other logic chips, or programmable devices. A propeller or two could still be used for clocking, loading a bootstrap program to ram, and some I/O interfacing like serial and parallel ports, sd cards, a text video terminal, and keyboard etc.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-26 00:33
    John A. Zoidberg
    The 6502 and the Z80 are easier to work with due to the address lines being separate instead of shared.
    Are you sure? As I recall all those micros use the same physical address pins to select I/O devices and memory.

    The difference between memory mapped and I/O mapped peripherals being that the latter has a additional signal to indicate if the current access is for memory or I/O. This puts I/O registers in a different address space logically.

    For example, during an I/O access the Z80 uses the low 8 bits of the address bus to select the peripheral register.

    It's not clear to me that I/O mapped devices are easier to work with. After all the is that extra memory/IO select pin to deal with. There probably is not much in it though.
  • GadgetmanGadgetman Posts: 2,436
    edited 2015-04-26 02:59
    What he probably means with the address lines being separate is that on the 6502 and the Z80, the address bus uses 16 pins on the CPU, and the Data bus another 8 pins, while on other CPUs such as the 8085, the addres bus shares 8 of its pins with the data bus.
    On a 8085, you need an external latch to 'capture' the lower Byte of the address and hold it before the bus changes function.
  • Heater.Heater. Posts: 21,230
    edited 2015-04-26 03:31
    Ah, yes. I see what you mean. I read it totally wrongly. That address latch and it's control signal do make things annoyingly more complex.

    I'd be tempted to just use the traditional TTL for these little bits of random logic. Use a Prop or two for peripherals.

    It should be possible to use a Prop to simulate the boot ROM.
  • mstrammstram Posts: 49
    edited 2015-04-26 10:19
    Hey there,

    Somewhere in the internet, managed to find some person who placed a Propeller to support an actual 65C02 processor - it looks like a fun job where new and old mix together. I believe the name is Propeddle by Jac Goldsmith, if I'm not mistaken.

    Could I use a big, fast microcontroller ( with a lot of pins ) as an address-decoder to support the classic processor like 6502? At the least I do not have to wire up too many latches and buffers on the breadboard.

    Well that's basically what the Propeddle project IS doing.

    Here are some other links re: microcontrollers / 6502 :

    http://forum.6502.org/viewtopic.php?f=1&t=2854

    http://www.obelisk.demon.co.uk/electronics/sb-6502.html

    http://code.lardcave.net/entries/2012/10/06/173014/
  • kwinnkwinn Posts: 8,697
    edited 2015-04-26 10:39
    Heater. wrote: »
    Ah, yes. I see what you mean. I read it totally wrongly. That address latch and it's control signal do make things annoyingly more complex.

    I'd be tempted to just use the traditional TTL for these little bits of random logic. Use a Prop or two for peripherals.

    It should be possible to use a Prop to simulate the boot ROM.

    It's a bit more complex than a Z80, 65xx, or 68xx would be, but with 2 or 3 latches, a few gates, some ram, and a propeller or two you should be able to build a system. Use a prop to feed the V20 nop's after reset so it generate addresses, have the prop write the boot code to the ram, and then reset the V20 once more to execute the boot code. Might even have enough pins and memory left on the prop to use it as the video terminal.
  • CuriousOneCuriousOne Posts: 931
    edited 2015-04-27 04:56
    Z80 is still very capable CPU.

    Just check this music example - same hardware, but coding techniques changed dramatically in 30 years.

    https://www.youtube.com/watch?v=QZnOd_f9YjQ
  • kwinnkwinn Posts: 8,697
    edited 2015-04-27 05:10
    CuriousOne wrote: »
    Z80 is still very capable CPU.

    Just check this music example - same hardware, but coding techniques changed dramatically in 30 years.

    https://www.youtube.com/watch?v=QZnOd_f9YjQ

    No arguments here. I used the Z80 to upgrade/repair a lot of equipment over the years. Until I found the propeller that is.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-04-28 17:46
    kwinn wrote: »
    It's a bit more complex than a Z80, 65xx, or 68xx would be, but with 2 or 3 latches, a few gates, some ram, and a propeller or two you should be able to build a system. Use a prop to feed the V20 nop's after reset so it generate addresses, have the prop write the boot code to the ram, and then reset the V20 once more to execute the boot code. Might even have enough pins and memory left on the prop to use it as the video terminal.

    Yeah, that will be cool too. I liked that suggestion of yours.

    I'm still waiting for the chips to come to my doorstep. While waiting, I prepared that breadboard and those supporting components first. :)
  • kwinnkwinn Posts: 8,697
    edited 2015-04-29 05:40
    Yeah, that will be cool too. I liked that suggestion of yours.

    I'm still waiting for the chips to come to my doorstep. While waiting, I prepared that breadboard and those supporting components first. :)

    You might want to post a block or schematic diagram and outline of how you plan to proceed so the forum members can make suggestions and point out potential problem areas. It always helps to have multiple eyes look over a project.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-05-01 10:28
    kwinn wrote: »
    You might want to post a block or schematic diagram and outline of how you plan to proceed so the forum members can make suggestions and point out potential problem areas. It always helps to have multiple eyes look over a project.

    Hello, here's the basic outline - I have not drawn the A16-19 and I'm still thinking how am I gonna proceed to use all the 1MB address space.

    8088 diagram start.png


    Pardon me for the lack of microprocessor knowledge - I've only worked with PIC microcontrollers, but on microprocessors, it'll be a bit overwhelming at start.

    And I'm using a graphics tablet to draw the schematic too.
    959 x 902 - 36K
  • kwinnkwinn Posts: 8,697
    edited 2015-05-02 14:07
    Close, but the A16-19 address lines are multiplexed, which would be a problem for the chip select decoding. Better to add a '373 to latch the address and decode the latched address as per the attached diagram.

    The address buffering and decoding is the easy part. The propeller will need to input and output several control signals from/to the V20 to control it. That will require reading and understanding the data sheet and some serious PASM programming.
    900 x 535 - 19K
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-05-05 02:19
    kwinn wrote: »
    Close, but the A16-19 address lines are multiplexed, which would be a problem for the chip select decoding. Better to add a '373 to latch the address and decode the latched address as per the attached diagram.

    The address buffering and decoding is the easy part. The propeller will need to input and output several control signals from/to the V20 to control it. That will require reading and understanding the data sheet and some serious PASM programming.

    Thanks for the opinion. I plan to use a Propeller or two of it for external peripherals so that some of the BIOS interrupts are utilized, especially the video ones.

    For simplicity, I used a 512kiloBytes RAM (4 mega-bits) for the RAM, and another 8k EEPROM for the firmware. However, since I do not have an EEPROM programmer, I'll try to use a Prop as an EEPROM emulator (small size).
  • kwinnkwinn Posts: 8,697
    edited 2015-05-05 05:31
    Thanks for the opinion. I plan to use a Propeller or two of it for external peripherals so that some of the BIOS interrupts are utilized, especially the video ones.

    For simplicity, I used a 512kiloBytes RAM (4 mega-bits) for the RAM, and another 8k EEPROM for the firmware. However, since I do not have an EEPROM programmer, I'll try to use a Prop as an EEPROM emulator (small size).

    I was going to suggest using a larger ram chip in my previous post but got interrupted and posted what I had. Using a larger ram chip is a good idea. It makes wiring or pcb layout much simpler.

    Using the propeller as an eeprom emulator would work but ties up a lot of pins. Once you have it though it could also do the address decoding for a second propeller, leaving most of it's pins free for I/O.

    The propeller also makes a good eeprom/eprom programmer with a few buffer/driver chips and some pasm code.
  • Cluso99Cluso99 Posts: 18,069
    edited 2015-05-06 13:42
    Rather than using an EEPROM, have the prop copy the code to part of the RAM on bootup while keeping the Z80 in reset. Then release reset and also use this line to disable writing to those RAM addresses that are being used as EEPROM.
  • kwinnkwinn Posts: 8,697
    edited 2015-05-06 19:36
    Cluso99 wrote: »
    Rather than using an EEPROM, have the prop copy the code to part of the RAM on bootup while keeping the Z80 in reset. Then release reset and also use this line to disable writing to those RAM addresses that are being used as EEPROM.

    Writing the boot code to ram is the way to go, and with a Z80 it would be relatively simple to do. John wants to use a V20 or 8088 which is a bit more complicated, but I think still doable. With the P1 limitations a two stage boot would be worth considering. Have the Propeller load a simple boot program to the V20 ram, and have the V20 execute that simple boot program to load the bios.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-05-07 08:30
    I'm building an "EEPROM Emulator" - using a Prop/other MCU to load the contents into the SRAM (as EEPROM) which is also connected to the V20/8088.

    The preliminary testing is I put a "lorem ipsum" text into the SRAM, wait a minute and read it back to see if the operation of the SRAM is correct or not.
  • kwinnkwinn Posts: 8,697
    edited 2015-05-08 10:03
    Should not be a problem to have the propeller write to SRAM. I used two Propellers and a CY7C1049DV33 512K sram as a serial concentrator/data buffer. Writing and reading the data was simple. Of course the Prop and ram chip were both running at 3.3V, which made it simpler.
  • John A. ZoidbergJohn A. Zoidberg Posts: 514
    edited 2015-05-09 08:51
    kwinn wrote: »
    Should not be a problem to have the propeller write to SRAM. I used two Propellers and a CY7C1049DV33 512K sram as a serial concentrator/data buffer. Writing and reading the data was simple. Of course the Prop and ram chip were both running at 3.3V, which made it simpler.

    I've already built the EEPROM emulator - using the walking ones test, and try to read back the "lorem ipsum" text successfully.

    My tactic is now to shut off the V20 while programming the eeprom emulator. Only after programming, the V20 will reset and resume operation.

    Since I don't have the Intel 8284 (oscillator), I built an equivalent of this by using a small Atmega (they have an frequency out pin) and handcrafted the code with a on/off output to the V20's reset pin.
Sign In or Register to comment.