3-Chip ROMless designs have been done in the past, using a microcontroller to load up the RAM.

However, all the ones I've seen so far have had the whole address and data bus wired up to the microcontroller. To save microcontroller pins, I came up with a much simpler design, that also works for CPUs without a BE input. It's so simple, it doesn't even need a circuit diagram.

The data bus is wired to the microcontroller, CPU and RAM, while the address bus is only wired between the CPU and RAM. The microcontroller also provides the clock and reset signals.

At startup, the microcontroller can put instructions directly onto the data bus. To load up the memory, it would use LDA, STA repeatedly to write to memory, without needing direct control of the address bus.

I haven't got the RAM wired up yet, but I have the CPU executing instructions straight from the microcontroller (Arduino nano) as a proof-of-concept. The code tells it to jump between 0x5555 and 0xAAAA repeatedly, which means I can put some LEDs on the address lines to verify that it works. I have attached some images of the system in action.

This is the Arduino code I used:



I'm planning to buy some surface mount parts, and get a tiny board made once I finish prototyping.

Getting away with three chips was the purpose behind the 6530 and 6532 RIOTs (RAM, I/O, and Timer, all in one IC) of yesteryear. The RAM afforded some ZP and page-1 storage space. Those were NMOS only, and probably never exceeded 1 or 2MHz, but they allowed a system with 6502, EPROM, and RIOT, before the days of workbench-programmable microcontrollers. I'm not aware of any workbench-programmable 6502-based microcontrollers that might have ever been available, but there are still the 65134 and 65265 microcontrollers which can use external ROM.

I do like your idea though!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yup -- not needing to control the address bus means there's a lot less wiring required. And, the idea isn't restricted to microcontrollers. Some of us still have access to PC's with real parallel ports, and they can accomplish the same thing -- perhaps more conveniently. (Hmmm. It might be possible to use a USB parallel port -- haven't looked into it.)

Either way, PC or microcontroller, naturally you need to avoid bus contention when the CPU on the target board is doing a write. An optional, quick 'n dirty shortcut for this is to use a set of 8 series resistors, 10K maybe, between the host and the target. The advantage is simpler control, since there's no need for the host to go tristate. The resistors limit current flow, preventing upset or damage. (The disadvantage is you lose a lot of speed -- but who cares, it's just the bootup.) (Also, devices on the target board's bus must present practically zero DC loading, which means they need to be MOS or CMOS only, no LS TTL -- and, again, who cares!)

Speaking of "a lot less wiring required," somewhere on the net I saw a bootup scheme for Z80 in which the host computer connected only to the Z80 clock and interrupt lines. (And reset, I guess, but still it was downright astonishing.) The gist of it was to stick the bytes in memory using the stack pointer as it responds to interrupts. You can control what byte-value gets pushed by controlling what address you're at before the interrupt hits -- and that, in turn, is controlled by clocking through piles of NOPs. (I know I'm missing a lot of details, because I make it sound pretty easy.) Anyway, it sure opened my eyes about what can be accomplished, even with absurdly restrained resources.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(Perhaps http://www.z80.info/jmz8boot.htm)

I like the idea of jamming data onto the bus - the only trick is cycle-counting so you know exactly which cycle is which as you present the opcodes and the data. I think the test mode of the 6500/1 worked like this - it was used to dump the ROM of one of those inexpensive pen plotters. See http://e4aws.silverdr.com/hacks/6500_1/

Thank you, Ed -- yes. Talk about "a lot less wiring required" !! Here's the entire computer. And only Clock, Reset and NMI connect to the host. Unfortunately, this doesn't seem like it could work for 65xx since, following reset, at least, there's no 16-bit stack pointer. But Z80 is probably not the only CPU that would work.

Yeah, the cycle-counting has to be right. But it's not horribly complex. Mostly there'd be just a series of five-byte sequences, like this:

• $A9 ($A9 is the opcode for LDA #)
• <a byte you want to store>
• $8D ($8D is the opcode for STA absolute)
• <ls portion of the address where you want the byte stored>
• <ms portion of the address where you want the byte stored>

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Not a three chip design, because it implements VGA output PS/2 keyboard and other features, but that's exactly what I have done with my breadboard computer Romulus 1st http://forum.6502.org/viewtopic.php?f=4&t=3458. Michael has done something similar and called it blind load. Not having a slow ROM speeds up the computer quite a bit. Even my proof of concept on breadboard runs at 11MHz.

My L-Star project is basically a 2-chip 6502 computer: it uses a Propeller and a 65C02 to make a working system. Well... I admit it really takes 3 chips because you also need an EEPROM to make the Propeller work. But that's not connected to the 65C02 so I could argue that it doesn't count .

The Propeller is connected to the address bus and data bus, R/~W and the clock. The Propeller is programmed through a serial port that can also be used as terminal. That leaves 3 pins on the Propeller free for monochrome video and a PS/2 keyboard. I have working software to emulate the Apple 1 and the OSI Superboard II (also known as the OSI Challenger or UK101).

This is a picture of L-Star on a Propeller proto board. Obviously there are more chips on the board because this includes a power supply and an FTDI chip for the serial port. But all I needed to solder on there to make it work was the 65C02, two pull-up resistors and a reset button.



The version in the picture doesn't have a PS/2 or video out connector because it's the simplest possible version. I also made a custom PCB that does have the connectors, and also has a power supply, an expansion header and a static RAM chip.

The 65C02 has complete control over the address bus but that's not a problem: The Propeller can bitbang a ROM image onto the data bus to let the 65C02 boot. It can also emulate I/O hardware such as the PIA on the Apple-1 to get text in and out. The RESET line of the 65C02 is not connected to the Propeller but when the system starts, the Propeller can generate BRK instructions and when the 65C02 retrieves the IRQ/BRK vector, the Propeller can feed the address of what's normally the reset vector. This works most of the time but not at power-up time: the 65C02 is jammed at that time and needs an actual reset, so the pushbutton is necessary.

See http://hackaday.io/project/3620 for more info...

===Jac

Zac, your previous design used some glue logic to multiplex some of the propeller pins. Now looking over your instructions it looks like a straight connection to it.

I'm curious, why the change in design direction?

The multiplexed address bus and control signals on Propeddle made it possible (in theory) to let the Propeller do cool stuff like generate interrupts and reset the 6502. It was an improved version of Dennis Ferron's Prop-6502 project: in his project, only 8 pins of the Propeller were used to multiplex the data bus and address bus, but I figured out I wouldn't be able to run that design at much more than 100kHz. I wanted to run at 1MHz so I used 16 pins instead of 8.

When I started on L-Star, it was intended as a simple side-project to see if I could answer to the "challenge" to create a two-chip (three if you count the EEPROM) Apple-1 emulator. That was surprisingly easy.

But once I had put L-Star together, I realized that that whole multiplexing thing had been a pain in the you-know-what anyway:

• The control cog in the Propeddle project (which generates the clock and takes care of the multiplexing) had to do so much that I needed a spreadsheet to lay out the Propeller Assembler instructions to make sure that everything would get done in 1 microsecond.
• I intended the Propeddle as a learning/teaching tool, but I had trouble writing comprehensive documentation for the control cog, this raised a red flag: if you can't make anyone else understand, your design may be too complicated
• When I started writing other modules for Propeddle, I realized that the multiplexing made it harder to get their timing right, too: Those other cogs had to pick up the address bus value at the right time (before it was gone because the control cog had taken the address off the Propeller pins), and it still didn't give those other modules time enough to do things like raise an interrupt before the end of the clock cycle.
• The extra glue logic made the circuit and PCB more expensive (more than $100 retail). I felt that that would be too much for the casual customer browsing on a website for a useful project that they could do on a rainy Sunday afternoon.

So even though I intended L-Star as a proof-of-concept at first, I eventually decided that this would be a good way to do a clean break from Propeddle. L-Star doesn't need a separate cog to control the multiplexers, it only needs to control the clock and that can be done in Spin (or an external clock can be used, see my KimStar project). Dennis Ferron's cool algorithm to load data directly to the RAM from the Propeller while the 6502 is executing fake instructions can't be used anymore because the Propeller doesn't control the direction pins of the RAM chip anymore, but that's not a show-stopper.

L-Star only has 3 pins available for I/O (plus 2 pins for the serial port). This is certainly a limitation but it's surprising how far you can get with just that. The Apple-1 and OSI Superboard/Challenger work just fine and I think I should be able to emulate a PET, which is what I wanted to start Propeddle for in the first place, 5 1/2 years ago. I'm also playing with the idea to create the first expansion board which will emulate the Elektor Junior and KIM-1 keyboard and 6x 7-segment LED panel. If there's enough space, I'll also put a Propeller on there with a VGA or PAL/NTSC video configuration.

===Jac

Hi David:

I learned about this blind loader method several years ago when I came across Nicholas FitzRoy-Dale's Hardware SID Player article.

I'm expanding the method and working on code for a 'blind monitor'. Basically a full blown monitor with memory read/modify commands, mini assembler and disassembler, and a 'flash' command to copy a block of upper RAM to PIC flash memory for the loader function. The 'blind monitor' runs in an otherwise unused 16 byte block of addresses within the I/O address space.

You might utilize other microcontroller features to reduce the amount of 'glue' chips required for a design. Just add CPU, RAM, VIA and/or ACIA to the example below for a 'minimal' system with 60K RAM and 4K I/O address space (including a 'blind loader' and 'blind monitor'). All that in a single 20-pin 'glue' chip... very cool.

Good luck in your research... Cheerful regards, Mike

@Jac, you should be able to use an I2C bus to add many devices to the L Star. The Propeller could then memory map them into the 6502's address space.

This intrugues me. I have thought of a way to make similar system with a 6502.

There are two main difficulties that must be overcome. Firstly, the SP starts in an unknown state. Secondly, an interrupt also causes the status register to get pushed to the stack.

So, here's the plan:

The microcontroller (MCU) is connected to clock, NMI, reset on the 6502. It also controls the CE signal for the RAM.
The 6502 data pins are pulled up/down into the NOP instruction. Data pin 5 will also be connected to the MCU as an input (I'll explain why shortly).
That's a total of 5 MCU pins.

Boot process:

The RAM CE pin is unasserted.
The MCU resets the 6502. The PC is now 0xEAEA.
The MCU clocks in NOPs until the program counter is 0x0000.
At this point, the MCU enables the RAM, triggers an NMI, and then disables RAM again, pushing 0x0000 somewhere on the stack. It also pushes the status register, which always has bit 5 set.
The MCU clocks in NOPs until the program counter is 0xFFFF. At this point, it triggers another NMI in the same way.
This process of pushing 0xFFFF is repeated, until the stack is full. (After each NMI, the PC will be at 0xEAEA again, so more NOPs will be needed for each push.)

Now, the MCU clocks in NOPs until the PC is at the start of the stack.
During the instruction read cycle, the MCU temporarily enables the RAM, and reads the value of D5 - If it is low, then it must be the 0x00 that was pushed previously.
The RAM is then disabled again so that only NOP is actually executed.
It scans through the stack by executing NOPs until it finds the 0x0000 sequence. When we find it, we can now deduce the current value of the stack pointer. (Problem 1 solved!)

Then, the MCU triggers NMIs until the SP is 0xFF.
Using the NMI technique, the MCU pushes 0x68 onto the stack. We now have the PLA instruction at a known memory location.
When we want to run the PLA instruction, we NOP until the PC is in the right place, and then enable the RAM when the instruction is being read.
Because we can now run PLA after each stack push, we can write continuous data to the stack (The status register part of the stack can be overwritten).

At this point, we can write a second-stage bootloader onto the stack. This secondary stage bootloader can read in data, one bit at a time, using bit 5 of the data bus.

I hope all that made sense!

P.S. After some more thinking, any bit could be used, rather than bit 5 - The 0x0000 sequence will still be detectable even if the status register state is unknown.

Edit:
If D0 was chosen for the MCU input, it would simplify things. Rather than pushing 0x0000 and 0xFFFFF, we could simply push 0xEAEA and 0xEBEB (since only the LSB matters, and the PC will be 0xEAEA after each NMI)

There's just one problem with that: the system uses SCL as clock for the 65C02 (and holds SDA high to prevent interference from I2C devices). If I would want to use the I2C bus e.g. to use the EEPROM as storage, or to access other I2C devices, I would have to stop the timer that generates the 65C02 clock, stop all the modules that "listen" to that clock to take action on the 65C02 bus, and hold RDY on the 65C02 low as long as I'm using the I2C bus for I/O.

I came up with the idea of sharing SCL between the I2C bus and the 65C02 clock when Vince Briel and I were working on his Superboard II replica, and we ran out of pins. I definitely considered the disadvantages listed above, and I did it again when I designed L-Star, and every time I thought about it, I decided it was still a good compromise. L-Star is a standalone system that has just enough pins to generate monochrome video and use a PS/2 keyboard and a RAM chip. Sacrificing another pin on the Propeller to separate the clock from the I2C bus to make it possible to use I2C at the same time as using the 65C02, would take one of those features (keyboard, video, RAM chip) away, and that would be a show stopper. But for almost all use-cases for I2C that I can think of, some extra hardware is needed anyway, so that hardware might as well include another Propeller or another microcontroller (*). The only important use-case for needing the I2C bus without any extra hardware is if I would want to make it possible to use the EEPROM as tape emulator or disk emulator, and I'm 100% sure I can do that, and I'm fairly certain that it will be acceptable to stop the 65C02 while it's necessary to access the EEPROM.

So yes and no: Yes, the Propeller (and the L-Star design) allows more devices to be on the I2C bus. But no, that's not likely to happen because it would be a pain to program and most likely, the hardware would be on an expansion card which can have its own microcontroller.

===Jac

(*) For a future revision, I'm considering adding a PIC microcontroller with a USB port to the L-Star board, which would make all these problems moot anyway. I did a little bit of work with a Microchip PIC USB dev kit but ran into some problems, so that's a shelved project for the future.

Very nice, sir! I confess I doodled with a 65xx version myself, but, daunted by the 8-bit Stack Pointer, I set the problem aside. It didn't occur to me to use pullup and pulldown resistors -- an innovation which sets your approach apart from the Z80 version.

Borrowing your pullup/pulldown idea, I took another run at the problem and managed to develop a scheme which uses 3 signals from the host rather than 5. I cheated by adding two resistors and two capacitors!

Edit: see my subsequent post for a simpler version of the idea.


As shown above, the signal called TO_NMI drives both /NMI and -- via an RC network -- /Reset. Similarly, TO_PULL drives certain pullup/down resistors and -- via an RC network -- the logic that asserts RAM Output Enable. The pullups and pulldowns are arranged to produce both $EA (NOP) and $28 (PLP). The slow (1 ms, say) rise and fall transitions from the RC's won't matter because they occur while the clock is stopped -- I think I'm on solid ground when I say that. Here's the play by play:

After powerup, TO_NMI is brought low if it's not already. We wait 1 ms (eg) to ensure /Reset is also low, then, using TO_CK, feed the 65xx maybe 6 or 8 clock pulses, then stop. We bring TO_NMI high, wait 1 ms for /Reset to follow suit, then deliver 7 clocks to execute the reset sequence. Henceforth, TO_NMI remains high, as a rule. Only brief low pulses (to generate NMI's) occur.

TO_PULL is high, did I mention? The 65xx sees $EA on the data bus, and $EAEA is where the reset vector lands us.

Next comes a loop, repeated 64 times:
• We do NOP's until the PC equals $EA9A - 1, then execute an NMI by pulsing TO_NMI low and issuing 2 clocks while it's low. This brings PC to $EA9A. Now 7 more clocks for the interrupt sequence (and the interrupt vector takes us to $EAEA).
• Although the NMI pushed 3 bytes, we discard the last one by momentarily dropping TO_PULL and doing a PLP (4 clocks).
• We do NOP's until the PC equals $EAA2 - 1, then execute an NMI as before, again using PLP to discard the 3rd byte pushed

The stack page is now full of repetitions of the pattern $A2, $EA, $9A, $EA. Alignment is unknown (eg, starting from $0100 you might see, say, the 4th byte of the pattern first), but no worries -- if you run it you'll eventually execute LDX# $EA then TXS. So, that's what we do: run NOP's until the PC equals $0100, then enable memory reads (ie; drop TO_PULL and wait 1 ms) and deliver enough clocks to run the LDX# $EA and TXS sequence at least twice (to ensure recovery from any misalignment).

Now we know S = $EA! [Edit: the misalignment recovery means PC isn't known exactly. Possible remedy: another NMI, making PC=$EAEA and S= $E7. Still pondering this.] The rest is predictable. We inhibit memory reads (set TO_PULL =1 and wait 1 ms), then:
• do NOP's until PC= the last byte-pair of our actual boot program - 1. NMI the byte-pair to stack.
• do NOP's until PC= the 2nd-last byte-pair of our actual boot program - 1. NMI to stack.
• (etc until done)
• do NOP's until PC= the start of the actual boot program just pushed. Then enable memory reads, and let fly!

Comments welcome -- I hope there's nothing serious I've overlooked. One minor point is the RC delay of the pullup/down resistors driving the bus lines themselves. It won't be possible to instantly switch between $EA and $28; a delay must be allowed of perhaps a few microseconds (for a firmer figure you need to do the math or do an experiment). And of course LS TTL devices aren't permitted -- only (C)MOS. Finally, you might as well let Ck default to high and only momentarily pulse low, rather than vice versa. That's in case you ever end up dealing with a Rockwell or similar 'c02 which can't tolerate extended clock-low periods.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

This is a very interesting thread.

@Michael

I've seen you mention the PIC a few times. I cut my teeth with the PIC but then moved to Arduino and Propeller. I love the Propeller but I sometimes wonder if the PIC might be better suited for glue logic. Especially with the programmable logic blocks.

As @Jac has proven, the Propeller can certainly emulate the RAM/ROM/IO for a 65c02, but you're pretty much capped at 1 - 1.25 MHz. Which is fine many things.

But, how fast have you clocked the 65c02 using a PIC with it running as glue logic like you show in that picture?

In my design, I'm going to use the Propeller as audio/video devices because it is amazing for that kind of stuff. But I can't help but wonder how a PIC would handle everything else. UART, glue, ROM, etc.

_________________
Cat; the other white meat.