ULA replacement - could it work in 16-bit mode ?

[NormanDunbar]

You couldn't take the hint. I was waiting for a smart mouth come back. Not smart.

The rules are available, theres a whole forum. Enjoy your read. There's a link on each posting/reply page.
http://qlforum.co.uk/viewforum.php?f=13 ... 017117fa4a.

Nobody here is "fighting racism" using "grammar nazi" techniques, but your attitude and language was complained about and reported. You were asked to be nice, but you couldn't. You were warned but you couldn't just accept that and tried to be smart. You failed.

I haven't banned anyone up until now, so I'm puzzled as to why you think I've done it before. In fact, nobody has been banned from here until now. Edit my apologies, 2 people have been banned permanently. Before my time.

Your "naughty step" is two weeks. See you if you come back. Hopefully you will as you seem to be clued up on hardware, so have obviously got skills. Not that I would know, I know next to nothing about it.

If you do return, you will be welcome, provided you cut out the nasties. If not, you'll be gone. That would not be helpful to anyone. Think about it.

Feel free to implement your own QL Forum if you want, this one isn't mine, I'm merely one of the moderators helping out.

Cheers,
Norm.

[Derek_Stewart]

Hi,

I do not really comment on this type of negative messages, but having a history of being the brunt of negativity in the past.

I would like to say:

I am really happy the way the QL Forum is conducted and there should be a vote of thanks to the Admonistrators snd Moderators.

I would not want much change.

The only thing I see as an omission is a list of Adminstrators and Moderators.

This is just clarify the the situation of who is who.

Maybe a procedure should be put in place to appeal any Administrator or Moderator decesion.

Other that quite happy, back to sleep

[Peter]

The EC060RC66 consumes ~3W depending on pin loading which is a fairly small amount of heat but if this was made as something like a QL expansion card, it's not trivial - about as much as the regular QL's voltage regulator.

Don't worry too much about that, in practice it was even less on the Q60 mainboard. And that was still with a relatively large bus load.

The integration is a + and a - but it's mostly about getting it trulz 68k compatible. For now, unexplored territory.

For QL purposes, the only way I see is still the approach I took before the SMS license war, namely intercepting instruction fetches in external hardware for the misimplemented instructions that do not trap out.
But today even the fastest Coldfire has no chance to beat emulation anymore, so such a huge hardware and software effort is no longer justified.

At the time, this was the base for GoldFire (hence the name).

I know of course... if you have anything left from that time which would still save you work, I'd love to see you finishing a design with the MCF5102.

It does need substantial CPLD help to get onto a QL expansion board, but if it was made as a completely independent board, that would be simplified.

Even an independent board would make a beautiful machine - still significantly faster than the Q68 thanks to the caches and 32 bit data bus.

I would agree and I am surprised to see that low a price (though lack of the 40MHz part).

Was there a 40 MHz part at all? The manual does not list it. But to be honest, I would probably run the 33 MHz version at 3.5V and 40 MHz, as long as the setup/hold timings can be met, the bus load is small, and the junction temperature stays much below maximum.

Such a machine has some very nice aspects:
- Real Motorola CPU
- Much more compact than '060 and a real power saver
- CPU available in brandnew condition
- Practically unlimited supply for QL purposes
- Historical beauty as it resurrrects the Coldfire Idea

Just by the way, when I started some design work on a Q60 successor, I missed a multiplexed bus like the MCF5102 a lot. That saves a lot of FPGA pins. And when interfacing to SDRAM, at no performance cost.
If this was a '060 instead of a '040 at core, I'd be very tempted myself. If you are tempted, lets have a private talk in which way I could support your design.

[Nasta]

The EC060RC66 consumes ~3W depending on pin loading which is a fairly small amount of heat but if this was made as something like a QL expansion card, it's not trivial - about as much as the regular QL's voltage regulator.

Don't worry too much about that, in practice it was even less on the Q60 mainboard. And that was still with a relatively large bus load.

That's good to know. I was seriously thinking back then of having two, although it looks at first glance like overkill. What got me to the dea is how much extra hardware is needed to implement all the new faster functions IF you actually want to avoid some brute-forcing by software. Whan it was all added up, the cost of an extra CPU was very comparable, yet much more flexible, even if it was only used as an IO processor and did only very trivial tasks such as transfer data around. That rises the power needed but not as much as the IO CPU rarely works full time internally and by definition only up to half the time externally.

The integration is a + and a - but it's mostly about getting it truly 68k compatible. For now, unexplored territory.

For QL purposes, the only way I see is still the approach I took before the SMS license war, namely intercepting instruction fetches in external hardware for the misimplemented instructions that do not trap out.
But today even the fastest Coldfire has no chance to beat emulation anymore, so such a huge hardware and software effort is no longer justified.

IIRC V3 and V4 have full trapping of unimplemented instructions, hence the availability of emulation software. I could be wrong, it's been a while since I checked.
Not sure about the emulation speed, unless it's some sort of JIT compiler style emulation. That being said, there are some MPUs out there that could be very good at emulation due to the way they internally work, like ESP32 or XMOS. These have time staggered multiple cores (or rather virtual threads) that are event driven and staggering the cores to effectively be the emulated CPU pipeline would probably make this a fast approach even without it being a pseudo-compiler. Given that these MPUs are also SPI flash bootable, one could make a 'chip level' emulator, basically a bard with such an MPU on it, perhaps some bus buffers. But that would be a huge project...

At the time, this was the base for GoldFire (hence the name).

I know of course... if you have anything left from that time which would still save you work, I'd love to see you finishing a design with the MCF5102.

It does need substantial CPLD help to get onto a QL expansion board, but if it was made as a completely independent board, that would be simplified.

Even an independent board would make a beautiful machine - still significantly faster than the Q68 thanks to the caches and 32 bit data bus.

An independent machine would probably be the best way these days. That being said, even back then, there were some 'radical' departures from the original QL architecture, but these would be easier to cater for today, now that source code for Minerva and SMSQ/E is available. Also, back then it was a fairly integrated solution but without video, and today that would have to be integrated on the board, which of course begs the question of what and how to actually do for that. There are several approaches, but I will outline that in a separate thread, a sort-of mind experiment of how one would go about making some sort of a 'QL next' retro inspired machine today. The intention is more to have it as a sort of educational thing, on how old QL hardware and low level OS does things and how this could be leveraged to get a significantly expanded but still compatible machine.

I would agree and I am surprised to see that low a price (though lack of the 40MHz part).

Was there a 40 MHz part at all? The manual does not list it. But to be honest, I would probably run the 33 MHz version at 3.5V and 40 MHz, as long as the setup/hold timings can be met, the bus load is small, and the junction temperature stays much below maximum.
Such a machine has some very nice aspects:
- Real Motorola CPU
- Much more compact than '060 and a real power saver
- CPU available in brandnew condition
- Practically unlimited supply for QL purposes
- Historical beauty as it resurrrects the Coldfire Idea

Yes there was a 40MHz part, I had a few samples back then (and unwisely sold them). There was a separate bulletin with timings for the 40MHz version. Of course, overclocking would have been tried either way
I was actually given the MCF5102 user manual in print and a 25MHz sample by the late Stuart Honeyball who was also considering it for a design but by that time he had already moved on to other things so it was a sort of passing on of the mantle. I will always be sorry things turned out the way they did and it never saw the light of day.

Just by the way, when I started some design work on a Q60 successor, I missed a multiplexed bus like the MCF5102 a lot. That saves a lot of FPGA pins. And when interfacing to SDRAM, at no performance cost.
If this was a '060 instead of a '040 at core, I'd be very tempted myself. If you are tempted, lets have a private talk in which way I could support your design.

Yes, though the multiplexing at first seems like a problem, once SDRAM is in the picture, it makes things easier, and especially as you say, saving PLD pins. There are some small snags but they should be solvable by using a doubled SDRAM clock. Oh and I checked, the MCF5102 is 5V tolerant, though these days I would not bother with that on the CPU level, rather on the PLD level.
The original design used one CPLD to interface to a QL style bus, and this one needs to be 5V tolerant but basically run at 3V3 (since any swing over some 3V has no real function for TTL compatibility so it makes signal integrity a simpler thing). The main reason for that bus side was interfacing all the peripherals and boot flash ROM. The other one was the DRAM controller and general system decoder.

[Peter]

IIRC V3 and V4 have full trapping of unimplemented instructions, hence the availability of emulation software.

With V4e, the major problem for QL purposes are not the unimplemented instructions. The real challenge are those which have slight differences in flag behaviour compared to 68K, but do not trap out. I saw no other way but to intercept those instruction fetches in hardware, let the CPU see an illegal instruction, and invoke an exception handler, which would then read the real opcode from a hardware register and emulate it in software.

An independent machine would probably be the best way these days. That being said, even back then, there were some 'radical' departures from the original QL architecture, but these would be easier to cater for today, now that source code for Minerva and SMSQ/E is available. Also, back then it was a fairly integrated solution but without video, and today that would have to be integrated on the board, which of course begs the question of what and how to actually do for that.

The best solution would probably be to take the Q68 or Qzero video controller, but with separate video RAM. Ideally, video RAM would be 32 bit wide, but the small extra latency using 16 bit at 80 MHz could probably be tolerated, assuming the MCF5102 at 40 MHz.

Yes, though the multiplexing at first seems like a problem, once SDRAM is in the picture, it makes things easier, and especially as you say, saving PLD pins. There are some small snags but they should be solvable by using a doubled SDRAM clock.

Not sure clock doubling would even be needed for full speed. (Unless one wants to reduce SDRAM bus width to 16 bit, which would further simplify layout and reduce parts count.)

The main reason for that bus side was interfacing all the peripherals and boot flash ROM.

Yes, but with SD cards now popular for QL use, a small 32 bit wide loader ROM inside FPGA would probably be the easiest way to do it today.