Power consumption of ZG6502 is quite low even at 32Mhz. 5V, 32Mhz running memory diagnostic is 90mA vs 60mA at 14.7mhz. The chips do not get hot, not even warm. I don’t overvoltage past 5.5V because current consumption go nonlinear, but performance only increases marginally, 5-10%. Colder temperature should improve CMOS performance, but you need to watch out for condensation.
36mhz 65816 is amazing. The few times I tried barely made to 30Mhz and not stable.
Bill
Zero glue logic 6502 SBC?
Re: Zero glue logic 6502 SBC?
In a previous life I designed circuits that had to work from -60C to +175C; well outside the nominal spec of their components. There was a lot of 'aha, this part works, keep it (but you can't use port A3)' in the design process...
One point is that as the temperature reduces, so does the band-gap voltage of a PN junction.
I suppose the issue with a 6502 depends whether it's cooled to dispose of waste heat, or cooled well below its normal operating temperature. Could be a fun experiment...
Neil
One point is that as the temperature reduces, so does the band-gap voltage of a PN junction.
I suppose the issue with a 6502 depends whether it's cooled to dispose of waste heat, or cooled well below its normal operating temperature. Could be a fun experiment...
Neil
-
BigDumbDinosaur
- Posts: 9425
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Zero glue logic 6502 SBC?
barnacle wrote:
I suppose the issue with a 6502 depends whether it's cooled to dispose of waste heat, or cooled well below its normal operating temperature. Could be a fun experiment...
Overclocking with higher VCC at a low temperature definitely qualifies as a form of “hillbilly engineering.” It’s kind of like dumping some nitromethane into your tractor’s gas tank...will it go or blow?
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Zero glue logic 6502 SBC?
What matters for the circuit function is the junction temperature, but what we have some control over is the package temperature. There'll be a temperature differential and there'll be a heat flow.
At higher voltages and at higher clock speeds there'll be increased heat generation on the die, which will increase the junction temperature.
The point of cooling is two things: heat removal, and lower temperatures, but both of those ultimately play to reducing the junction temperature to below what it would have been. Generally, lower is better, down to some rather low limit. The junction temperature will always be above the package temperature, and it's the package we can cool.
At higher voltages and at higher clock speeds there'll be increased heat generation on the die, which will increase the junction temperature.
The point of cooling is two things: heat removal, and lower temperatures, but both of those ultimately play to reducing the junction temperature to below what it would have been. Generally, lower is better, down to some rather low limit. The junction temperature will always be above the package temperature, and it's the package we can cool.
Re: Zero glue logic 6502 SBC?
High voltage and low temperature is the fastest corner of CMOS technology which also generates the most noises and cross talks. So one of the corner test cases is cold soak for an hour or two, then power up at max supply voltage and run through abbreviated test suits quickly before the junctions are warmed up. This is realistic case for equipments sitting in field fully charged and powered down. In the test lab we also overclocked one speed grade (33%) to account for potential component variations. Troubleshooting cold failures are painful.
Bill
Bill
Re: Zero glue logic 6502 SBC?
This project made me wonder how fast the 65C02 could go if it wasn't slowed down at all waiting for external devices. My idea was to take a recording of the bus activity while running a program (e.g. the Dormann tests), and then replay the data bus activity without external devices connected, removing all external propagation delays and other dependencies from the circuit. Then you could see exactly how much you could shorten each phase of the clock before the MPU became unreliable.
The recording would contain at least the data bus, but ideally also the address bus and RWB state. The data bus alone would be sufficient to replay the sequence of instructions, and during read operations the replay circuit could put the right value onto the data bus early in phase 1, with no need to wait for any propagation of the address bus pin states.
To check whether the MPU is deviating from the recording, you'd watch out for cases where it is driving the wrong value onto the data bus in a write operation, or where the address bus or RWB states don't match the expected values from the recording. If the address bus and RWB were not part of the recording then that's still OK, as they could be reconstructed by hoglet's decoder if necessary. As soon as any deviation occurs the MPU should be stopped, as it will no longer match the recording and risks contention on the data bus if we still go ahead with playing back the recording.
The challenge would probably end up being sampling all of the pins quickly enough. The Cypress FX2 logic analyser might be able to do 8-bit sampling at around 40MHz - it's certainly worked for me at 32.768MHz - but it might not go much faster than that. You could plug several into one PC, to sample more bits, but the PC itself might be the bottleneck. It might be necessary to capture to fast SRAM or something like that instead.
Asynchronous signals like RDY, NMI, and IRQ would be awkward, and probably best avoided at first, but could be simulated by running the data bus capture through hoglet's decoder to determine exactly when these things occurred, and then arranging for the signals to be generated during playback with plenty of setup time before the appropriate clock edge.
I hadn't thought this through very much but I thought it could be an interesting direction, to determine the absolute maximum speed for a 65C02 with all external dependencies removed.
The recording would contain at least the data bus, but ideally also the address bus and RWB state. The data bus alone would be sufficient to replay the sequence of instructions, and during read operations the replay circuit could put the right value onto the data bus early in phase 1, with no need to wait for any propagation of the address bus pin states.
To check whether the MPU is deviating from the recording, you'd watch out for cases where it is driving the wrong value onto the data bus in a write operation, or where the address bus or RWB states don't match the expected values from the recording. If the address bus and RWB were not part of the recording then that's still OK, as they could be reconstructed by hoglet's decoder if necessary. As soon as any deviation occurs the MPU should be stopped, as it will no longer match the recording and risks contention on the data bus if we still go ahead with playing back the recording.
The challenge would probably end up being sampling all of the pins quickly enough. The Cypress FX2 logic analyser might be able to do 8-bit sampling at around 40MHz - it's certainly worked for me at 32.768MHz - but it might not go much faster than that. You could plug several into one PC, to sample more bits, but the PC itself might be the bottleneck. It might be necessary to capture to fast SRAM or something like that instead.
Asynchronous signals like RDY, NMI, and IRQ would be awkward, and probably best avoided at first, but could be simulated by running the data bus capture through hoglet's decoder to determine exactly when these things occurred, and then arranging for the signals to be generated during playback with plenty of setup time before the appropriate clock edge.
I hadn't thought this through very much but I thought it could be an interesting direction, to determine the absolute maximum speed for a 65C02 with all external dependencies removed.
Re: Zero glue logic 6502 SBC?
oh, a tool-assisted speed run!
Re: Zero glue logic 6502 SBC?
gfoot wrote:
This project made me wonder how fast the 65C02 could go...
The Picos could take the '816 off the bus (using BE which thankfully affects RWB too). With the '816 disconnected it could then write a program into the SRAM then reconnect it, start the clock and release reset.
And that was it. Not practical as a computer but useful for testing.
Once time had passed and I guessed the '816 was done running whatever program it was given then the Picos would take it back off of the bus and read the SRAM. And - all things being stable - that memory contents should match what I expected. There were so, so many problems on that test board though.
I've since designed - but not fabricated - a more practically useful board where the overclocked '816 sits on an isolated bus with only a 1MB SRAM. Isolated from another much slower '816 that can take control of that bus to read and write that SRAM. And of course the slower '816 can do full device address decoding. The ultimate goal is to turn the fast '816 into a glorified maths co-processor*
* and because it's me and I can never let something stop at simple I'm trying to stack four fast co-processors on top of each other... don't ask
Re: Zero glue logic 6502 SBC?
gfoot wrote:
This project made me wonder how fast the 65C02 could go if it wasn't slowed down at all
Does the Cypress FX have the ability to play back the recording or would you be ticking it out of some purpose built memory board?
Re: Zero glue logic 6502 SBC?
AndrewP wrote:
Does the Cypress FX have the ability to play back the recording or would you be ticking it out of some purpose built memory board?
Re: Zero glue logic 6502 SBC?
George,
In term of minimizing loading and feeding instructions to a 6502 as fast as possible, a fast FIFO may be a possible solution. A 4K FIFO is easy to find, so that’s 4K worth of instruction stream. FIFO empty/full can connect to 6502’s RDY to stop execution while next 4K is loaded.
Bill
In term of minimizing loading and feeding instructions to a 6502 as fast as possible, a fast FIFO may be a possible solution. A 4K FIFO is easy to find, so that’s 4K worth of instruction stream. FIFO empty/full can connect to 6502’s RDY to stop execution while next 4K is loaded.
Bill
Re: Zero glue logic 6502 SBC?
Neat project I'm sorry I missed this one earlier.
At those speeds you could make a VGA display controller. VIA port A could be used for output with three bits of red, three bits of green, and two bits of blue. Port B could provide h sync, v sync, and the I2C bus pins.
Could dual ported RAM to connect it to a host system? The barrier would be the slower clock rate of that system.
At those speeds you could make a VGA display controller. VIA port A could be used for output with three bits of red, three bits of green, and two bits of blue. Port B could provide h sync, v sync, and the I2C bus pins.
Could dual ported RAM to connect it to a host system? The barrier would be the slower clock rate of that system.