68080 on Firebee

[Thenesis]

Can he not get 4 or 5 new machines for the price of a 30 year old used Falcon?

If a V4 (or a FireBee, if that matters) is considered a suitable replacement for an original Atari for you (both aren't 100% compatible, both aren't 100% complete and both aren't exactly cheap), then, well, you might be right. If you want to have something fast and don't care if every old application will run, that's your choice (if you can afford it).

It really depends on what you want - if you just want to play old games with near 100% compatibility, you might be better off (and way cheaper) if you get a MiST or the new Tang Nano.

The best is to have a V4 AND a MiST.

Ideally the V4 (V5 ?) should have an expansion slot to add a MiST-like card so that we could start everything from the same machine. You cannot have both a cycle accurate AND a fast 68k in the same FPGA (mainly because of the license but also because the MiST needs its own memory for cycle accurate timings, it would require ~50 additional pins for a dedicated SDRAM).

[Xyla]

why worry about something like the 68080 if the goal is not to make the Firebee something that can completely replace a CT60e Falcon?

Are we mixing up two topics here?

I have the impression you mix up the topic of Firebee and Falcon - with the topics of different 68k CPUs.

I'm not sure... but I don't think I was mixing anything up? This topic was about giving the Firebee a closed-source soft CPU FPGA core with licensing fee (68080)... which just seems very questionable to me. It's not lacking in CPU power, the Coldfire has a variation of the 68k instruction set. I don't really see what would be gained by doing this. Where the Firebee is lacking is the graphics are slow, especially at high resolutions. I don't think replacing the Coldfire with 68080 is going to help that.

The APOLLO 68080 is a member of the 68K CPU family like the Motorola 68060.
In internal design the APOLLO 68080 is a highly improved 060 CPU.
The Apollo 68080 reaches higher performance than the Motorola 68060 both in total and per clock cycle,
it reaches a lot higher memory performance (like 10 times higher than the 060)
and it re-adds all the instructions that the 68060 lost,
therefore compatibility with old software can be higher.

Yes you're absolutely right that compatibility would be higher... but I would think the Firebee compatibility could be improved without dumping the Coldfire, which is also effectively also a member of the 68K CPU family and reaches higher performance than the Motorola 68060.

Is whether you want to use the Apollo CPU in something like the Firebee, or in the V4-Standalone, or in an Falcon itself - not a complete different topic?
If you like your Falcon the most, then maybe upgrading your existing Falcon using a APOLLO 68080 CPU is something you could also discuss.

I think it would be great to see something like a Vampire V4 that is designed to go in real Ataris or as a standalone Atari compatible... exactly how it is for the Amiga. I'm just not sure what that has to do with the Firebee... which is already an Atari compatible with an enhanced 68k CPU. If there's lots of room in the Firebee's Cyclone, It would be better used for some kind of super-blitter GPU to enhance the graphics power.

[1st1]

Did many new users came to Atari because they got a new Falcon?

Not many. Only 14.000 have been produced and it was quite expensive, plus a little unknown number of Steinberg made Falcons. ATARI also did allmost no publicity for it, even inside the scene. It was ATARI's last computer and the most of them have been sold in Germany which was one of te most engaged countries in that scene (Germany, France, UK, Scandinavia, Netherlands was the hotspot in Europe at that era - even US and Canada was not that strong scene). Also software using the special features of the Falcon at the original era was not quite big. So why comming from another system to this one? For the ATARI freaks it was anyhow the final dream machine (maybe similar like A4000 for most Amiga guys at that time) but many of them - if they even knew about the machine. And - like in the Amiga scene - most of the Atarians turned onto Mac or PC at that time as it was cheaper / more powerfull / more modern software choice / ... instead of upgrading to the bird of prey.

So what we don't know, how many Falcons have survived, how many have been scrapped already? Is the number of 14.000 is really true? How big the "scene" is actually, potentially ready for the ultimative upgrade of the beast? Some reading here might be jealous if I say that I have three of these rare birds.

So as a Falcon owner a A68080 turbo card might be interesting for me for one of them, depending on the costs. The nice side of this idea that I would not care wether you integrate the 56k DSP or not, because it's already there. MMU still would be interesting because of mem protection in MiNT and some usefull tools which use it. But... One of my birds has already 68060 overclocked (stable) at 95 Mhz, 512 MB RAM, this is enough for all existing applications, games and demos and so on, even if they require turbo card like some good douzens of impressing scene demos, so no real pressure for another turbo card for me. On the other hand unfortunatelly I don't see any opportunity to get a supervidel graphics card for the ct60 turbo card's expansion slot as nobody manages to start another batch of these. With 68080 in Falcon this could be solved with supervidel emulation or SAGA. But the only applications supporting the 68080 optimized things like mplayer for watching high resolution videos, does that make sense, being able to use the Falcon as a DVD player?

On the other side, as this beast (Falcon) is so rare and guys like me are sitting on them like a dragon on it's hoard, or others selling them for silly high prices, currently 1200 Euros with some luck on a stock unrestaurated Falcon is "entry level", you can already observe twice or three times that price in the bay, there is the chance that a Vamp can fullfill the dream of peoples wanting a Falcon since years, having now the chance getting a "Super-Falcon" (Falcon 080), fully compatible (MMU, DSP, DSP-Port, Videl, YM/STE/F-Sound, Midi, ROM-Port/Dongle-Emulation for Cubase-Audio, Blitter, ...) and turbocharged (68080) and higher graphics modes (Super-Videl compatible, SAGA) plus maybe benefitting from some Amiga features (Amiga-Blitter, Copper, Sprites, Paula anyone? - where is the software for TOS/MiNT to support that?) ... showing these dragons where the hammer really is for an acceptable price. I think this may would even crack down some of the "small" group of old grey dragons already owning the grey original, but it also would be also the fullfillment of everyone else's dream to have a Falcon (or Hades, Milan, Firebee) ...

So, genug geschwurbelt, gute Nacht!

[Jinroh]

Did many new users came to Atari because they got a new Falcon?

Not many. Only 14.000 have been produced and it was quite expensive, plus a little unknown number of Steinberg made Falcons. ATARI also did allmost no publicity for it, even inside the scene. It was ATARI's last computer and the most of them have been sold in Germany which was one of te most engaged countries in that scene (Germany, France, UK, Scandinavia, Netherlands was the hotspot in Europe at that era - even US and Canada was not that strong scene). Also software using the special features of the Falcon at the original era was not quite big. So why comming from another system to this one? For the ATARI freaks it was anyhow the final dream machine (maybe similar like A4000 for most Amiga guys at that time) but many of them - if they even knew about the machine. And - like in the Amiga scene - most of the Atarians turned onto Mac or PC at that time as it was cheaper / more powerfull / more modern software choice / ... instead of upgrading to the bird of prey.

So what we don't know, how many Falcons have survived, how many have been scrapped already? Is the number of 14.000 is really true? How big the "scene" is actually, potentially ready for the ultimative upgrade of the beast? Some reading here might be jealous if I say that I have three of these rare birds.

On the other side, as this beast (Falcon) is so rare and guys like me are sitting on them like a dragon on it's hoard, or others selling them for silly high prices, currently 1200 Euros with some luck on a stock unrestaurated Falcon is "entry level", you can already observe twice or three times that price in the bay, there is the chance that a Vamp can fullfill the dream of peoples wanting a Falcon since years, having now the chance getting a "Super-Falcon" (Falcon 080), fully compatible (MMU, DSP, DSP-Port, Videl, YM/STE/F-Sound, Midi, ROM-Port/Dongle-Emulation for Cubase-Audio, Blitter, ...) and turbocharged (68080) and higher graphics modes (Super-Videl compatible, SAGA) plus maybe benefitting from some Amiga features (Amiga-Blitter, Copper, Sprites, Paula anyone? - where is the software for TOS/MiNT to support that?) ... showing these dragons where the hammer really is for an acceptable price. I think this may would even crack down some of the "small" group of old grey dragons already owning the grey original, but it also would be also the fullfillment of everyone else's dream to have a Falcon (or Hades, Milan, Firebee) ...

Good writeup. Where I was stuck there was no Atari scene or hardware easily available after a while. I sold all my hardware when I was younger, so I did not get back into the scene until it was too late for my getting the Falcon.

My friend was an Atari distributor in the U.S,. he told me the Tramiel's wouldn't even let him stock Falcons for some reason. A shame, though it is, what it is. The one he has, he had to buy just like everybody else.

Some kind of new Falcon 080, I think would be good. A punchy new Falcon successor. Aside from something like that, unless I can turn my Mega STe into a Falcon, or if someone wanted to trade my maxed out beautiful blue SGI Indy for a Falcon, I'm SOL.

[Gunnar68080]

Yes you're absolutely right that compatibility would be higher... but I would think the Firebee compatibility could be improved without dumping the Coldfire, which is also effectively also a member of the 68K CPU family and reaches higher performance than the Motorola 68060.

You say the Coldfire is a member of the 68K family.
Not sure if I would say this .. as the difference of the Coldfire to other 68K CPU are huge and significant.

As you know the 68000 and all other 68K CPUs support BYTE/WORD/LONG operations.
This means programs can manipulate directly BYTEs or WORD or LONGWORDS.
This is a very important and strong feature of 68K instruction set.
And in the ATARI you have lots of BYTE and WORD hardware registers and
of course existing programs use many BYTE and WORD variables,
so BYTE and WORD operations are for sure very numerous in existing software.

The Coldfire generally only support LONG. (with few exceptions).
This is huge difference.

The big strength of the 68000 family are its nice and good Address modes (called also EA modes).
The good address modes make the 68K such a nice CPU to program.
The 68000 family has EA modes like index mode with WORD Index (A0,D0.w) - which the Coldfire not supports.
The missing modes will make old programs often need to emulate the instruction.

Then there is the big difference in supported instruction length:
As you might know the 68000 CPU supports instructions of 2,4,6,8, and 10 Byte length.
The 68030 CPU in the Falcon supports instructions of 2,4,6,8,10,12,14,16,18,20, and 22 Byte length.
The Coldfire support instructions of 2,4, and 6 Byte Length
This is a huge difference and kills many EA modes.

Many typical simple instructions like move.l #immm,$adr are not supported on Coldfire.

And of course instruction like MOVEM which you use all the time in subroutines to save/restore registers - work differently.

And then there is a number of simply "dropped" instruction like for example DBRA.
DBRA the loop instruction of the 68K family is typically used in every loop in each program.
But its missing on the Coldfire.
Then Bitfield instructions are missing and many other instructions like e.g. MOVEP.
I thin some of these instrucitons like MOVEP are used a lot in existing ATARI software.

The Coldfire can trap on most of the missing instructions/ missing EA modes / missing length support
and a trap handler can emulate then the missing /real 68k instruction.
This works but of course is very slow .. in my experience much slower than an 68060 CPU for running real 68K software.

I think the idea of the Coldfire is to use it in a closed environment if you write all software new.
Like for example if you design a printer and the Coldfire runs the firmware inside it.
And you write all firmware from scratch without the need to run old software.
Then I think the Coldfire is good CPU.
To run old software, like for example Software for the Falcon 68030 CPU
i think this is very hard for the Coldfire as it will have to trap out on a huge number of instructions and will need software emulation a lot..
My experience with Coldfire trap and emulation overhead is that is pretty costly - it literally makes the CPU in the order of ~ 50-100 times slower.

I did a disassembly of the Amiga OS and wrote a program doing a statistic of how many instruction are in the small subset that the Coldfire
can execute without the need of software emulation. The amount of needed software emulation was so high in Amiga OS
that using a Coldfire would have been very slow. And of course there is also the topic of changed behavior of instructions.
There are some operations which the Coldfire does differently .e.g misaligned variables on stack etc - and these things can not be handled by software library help and can cause critical incompatibility.


If you compare the Coldfire V4 with the 68060 CPU...
then the 68060 has the advantage that it supports super scalar = can execute up to 2 instructions per cycle.
The Coldfire V4 is not super-scaler like the 060.. The V4 has a feature that it can sometimes execute some instruction in the EA unit which is not bad but less powerful as the 68060 two ALU units. Also in my use cases the Coldfire was relative weak in memory operations - often much weaker than the 68060 was in our tests. You mentioned GFX operation performance. In our GFX driver there are often areas/functions where the CPU is actually pushing pixels around - and here the memory interface performance of the CPU is a major factor - and I can see that the Coldfire was dissapointing us in this area.

All this said: I think the Coldfire is a very interesting CPU if you start from scratch.. If you develop a new system with new software that not needs to run old software at all.

Therefore I think for the FIREBEE using EMUTOS is a good idea.
With Emutos you can recompile the OS, so that the CPU not needs to trap out and emulate all the time.

[joska]

The Coldfire can trap on most of the missing instructions/ missing EA modes / missing length support
and a trap handler can emulate then the missing /real 68k instruction.
This works but of course is very slow .. in my experience much slower than an 68060 CPU for running real 68K software.

My experience is the opposite. I have spent *many* hours programming in C *on* a Firebee under FireTOS, and CPU performance and compatibility with 68k software was in general not a problem. Overall performance was good, in general better than my 95MHz Falcon/CT60. Yes, the 68k compatibility layer in FireTOS is a bit of a hack, but it works well. I eventually used the Firebee less and less and finally ended up selling it, but that was due to the lack of memory protection for it in MiNT. Yes, the Firebee has a lot of other issues which prevents it from becoming the Falcon replacement it was intended to be, but for my use it was really neat and only missed memory protection.

Today a V4 is a better choice. If MiNT at some point supports it's MMU I will buy one.

[mfro]

My experience with Coldfire trap and emulation overhead is that is pretty costly - it literally makes the CPU in the order of ~ 50-100 times slower.

I don't know where you got these numbers from (synthetic benchmarks, thin air?), but in my (practical) experience, they are way off.

To my experience, real Atari programs behave differently. More like maybe 50% slower at maximum (which is still way faster than any Atari ever was).

[Gunnar68080]

My experience with Coldfire trap and emulation overhead is that is pretty costly - it literally makes the CPU in the order of ~ 50-100 times slower.

I don't know where you got these numbers from (synthetic benchmarks, thin air?), but in my (practical) experience, they are way off.

To my experience, real Atari programs behave differently. More like maybe 50% slower at maximum (which is still way faster than any Atari ever was).

Maybe your experience is different to mine. I can tell you where I got my experience / these numbers from.
I was working with Motorola on a number of projects together. Some of their CPU errata was reported by me.
I was also testing Motorolas Coldfire Development System for Motorola long time before FIREBEE came out.
And I had also access to their new Coldfire V5 CPU under NDA.

Regarding the 50-100 slowdown per instruction for emulation.
This is of course a ballpark number but its very easy to understand.

Normally a CPU instruction is executed in hardware.
This means a simple instruction like
ADDQ.B #1,D0
Will execute very quickly in hardware. => 0.5 cycle on 68060 CPU.

While the Coldfire does support ADDQ.L #1,D0
The Coldfire does NOT support
ADDQ.B #1,D0
ADDQ.W #1,D0

So on these instruction the Coldfire CPU will cause a EXCEPTION.
This means it will store the PC on stack and also the flags this does memory access and takes some cycle.
Then the exception will take a number of cycle to fetch the vector and go to a "hopefully" installed handler.
This handler is a software.
Which software has to identify which instruction was causing the exception.
And after identify this the software routine has to jumped in an "emulation routine"
that emulated the behaviors including the creating of the correct flags.

This means you have
a) the time for creating the exception
and jumping into the handler
b) in the handler you have to save registers and
have to identify what real 68K instruction caused the exception,
and jumping into a small routine which "emulates" it.
c) the function emulating it will also have to emulate/create the register result and also create the proper flags
then the registers need be restored back and it needs to jump back into the program

There is a lot code called.
Many register need be saved and restored. = many memory access
And the code will cause plenty of cache misses.


Did you ever count the cycles that for example emulating of the very common DBRA needs?

Do you want me to "count cycles" for you for an Exception handler example to make this more clear?

Every 68k Coder will understand that this is a HUGE effort per emulated instruction.
And for sure every experienced Coder will understand that a 50-100 times
slowdown per emulated instruction was pretty generous and flattering already...
There are many cases taking more cycles.

Do you agree?

More like maybe 50% slower at maximum (which is still way faster than any Atari ever was).

In my experience an emulated instruction is a lot slower than 50%,
It takes more in the range of 50-100 times longer than a native instruction.

For the whole program saying its 50% slower, how could you say this?
To what do you compare it ?
Do you have a real 68K CPU like an 68060@266MHz to compare it to?

As the Coldfire can not execute the program native -
where do you get the 100% possible to compare too?


I speak from my personal experience.
My personal experience was that Coldfire was in executing real Amiga software
in average significant slower than Amiga with 68060 CPU and often also slower than AMIGA with 68040.
Of course every program is very different and the result do vary a lot.
There where good, and medium, and bad and very bad cases.
There were cases, where the coldfire ran like on 68060@50 and also cases were it ran like 10 times slower than a 68060 CPU

[joska]

I can of course only speak from my personal experience.
My personal experience was that Coldfire was in executing real Amiga software
in average significant slower than Amiga with 68060 CPU and slower than AMIGA with 68040.
Of course every program is very different and the result do vary a lot.
There where good, and medium, and bad and very bad cases.
There were cases were the coldfire ran like on 68060@50 and also cases were it ran like 10 times slower

My personal experience is that the Firebee runs 68k software at least as fast and often faster than my 95MHz Falcon/CT60, which again is faster than any 060 Amiga that I know of. True, software compiled for Coldfire is a lot faster than 68k software. E.g. compiling code with the 68k-version of AHCC was slower than with the Coldfire version, but still *fast* (in Atari terms) and also faster than on my Falcon.

Comparing the Firebee to my 40MHz 040-equipped Falcon is like comparing the 040 Falcon to an ST. Even when the Firebee is running 68k software.

That said, I prefer the 68080 over a Coldfire. 68k emulation is not perfect and many binaries has to be patched on the fly to work. But back when the Firebee was developed there was no such alternative.

[Gunnar68080]

Hello Jo,

I can of course only speak from my personal experience.
My personal experience was that Coldfire was in executing real Amiga software
in average significant slower than Amiga with 68060 CPU and slower than AMIGA with 68040.
Of course every program is very different and the result do vary a lot.
There where good, and medium, and bad and very bad cases.
There were cases were the coldfire ran like on 68060@50 and also cases were it ran like 10 times slower

My personal experience is that the Firebee runs 68k software at least as fast and often faster than my 95MHz Falcon/CT60, which again is faster than any 060 Amiga that I know of. True, software compiled for Coldfire is a lot faster than 68k software. E.g. compiling code with the 68k-version of AHCC was slower than with the Coldfire version, but still *fast* (in Atari terms) and also faster than on my Falcon.

The 68K family does support many instruction with many different sizes and many different Address modes.
This means we talk here about a huge number of a variations in totals.
E.g. 100 * 3 sizes *14 EA modes ... == huge number

The Coldfire supports
only a subset of instructions, x
then they only supports 1 Size, x
and it has major limitations on the EA modes.

This means the number of supported variations is only a fraction of the 68K family.
So maybe 20% of instruction variations of what the real 68030 does support.

In my experience every programs is very different, and the instruction mix is different.
You can create good cases in which a workloop is 100% covered by the Coldfire,
and there are also bad cases where you can have 50% only or less maybe even 0% native instructions in a workloop.

Our study on Amiga OS showed that AMIGA OS does use many WORD instructions
which the Coldfire not support and needs to emulate - this made it really slow.
This was our experience... you running different software might get a different result.

i think the FIREBEE is for sure a super interesting system.
We found that the COLDFIRE was not satisfying our needs.
And we decided that it for us makes more sense to spend 10 years developing a new real 68K - instead using the existing Coldfire which would have been very easy.

I think the Coldfire is a nice system.
And the emulation overhead can of course be lowered with providing recompiled programs and OS.
And also with the higher end Coldfire models like V5 and at that time the "planned vision" of the Coldfire V6@800Mhz ... would have made the overhead appear much smaller.

[mfro]

One thing we didn't discuss yet: most people using high end TOS machines run FreeMiNT (the UNIX-like multitasking system that runs on top of TOS) instead of plain TOS.

FreeMiNT (as the name implies) is OSS and as such (thanks to some hard-working individuals) also available in a ColdFire native version.

That certainly makes a difference as well.

[Gunnar68080]

One thing we didn't discuss yet: most people using high end TOS machines run FreeMiNT (the UNIX-like multitasking system that runs on top of TOS) instead of plain TOS.

FreeMiNT (as the name implies) is OSS and as such (thanks to some hard-working individuals) also available in a ColdFire native version.

That certainly makes a difference as well.

Oh yes this makes of course a huge difference.

But at the time when I did this evaluation the only AmigaOS (closed source) was a binary.
I had to disasm the OS for doing this study. Today the situation is different and we today
have ApolloOS which is a AmigaOS remake and of which we have the source.
But the old original AmigaOS was full of instructions the Coldfire does not support.
Each and every workloop was using unsupported DBRA LOOP instructions.
Each function using MOVEM that not works on COLDFIRE,
very many BYTE and WORD instruction that are not supported by the Coldfire.


If you have your own OS and your own Applications
and not need to run old original software then the Coldfire becomes a lot more useful.

[Gunnar68080]

OK I understood that its not easy to produce FIREBEE as a number chips you use are end of live, and probably hard to get now...

I assume you can get them from shady channels in China .. refurbished or otherwise...
This brings me to a silly question, have you Coldfire community, considered to use a Coldfire V5e?

For comparison the 68060 CPU can decode 2 instruction per cycle.
The 68060 has 2 Address calculation units and 2 ALU units.
This enables it to do up to 2 instructions per clock cycle.


The Coldfire V4e has 1 EA unit and 1 ALU unit.
The V4e can "normally" do up to 1 instruction per cycle.
In rare case it can cheat a little and "smuggle" in addition a very limited few instruction into the EA unit.



The Coldfire V5e has 2 EA units and 2 ALU units
The Icache of the V5 provides 64bit instructions per clock - this is good.
For comparison the 68060 only loads 32bit of instructions and this was its main weakness.
The 68060 design team did want to fix this and increase this to 64bit .. - but this was not done.
The V5 has this now .. (side note the design lead of the 68060 CPU was also in the Coldfire V5 team)
The V5 has a lot in common in pipeline design with the 68060 CPU.
The V5e can "normally" do up to 2 instruction per cycle.
This gives a V5 a lot more potential performance..
And some say that it also reaches 100% higher clockrate than the V4
in addition it has better branch prediction and some other improvements.

For Coldfire fans this means up to 3 times performance of the Firebee.
They are not easy to source ... but there is always ways.

[ragnar76]

This brings me to a silly question, have you Coldfire community, considered to use a Coldfire V5e?

They did but the V5e was sold to HP for the Printers only and they never make it to the open market. https://www.atari-forum.com/viewtopic.p ... 80#p333280

[vido]

This brings me to a silly question, have you Coldfire community, considered to use a Coldfire V5e?

If you can provide documentation for it, then yes?

[Gunnar68080]

This brings me to a silly question, have you Coldfire community, considered to use a Coldfire V5e?

If you can provide documentation for it, then yes?

In my experience you can often get documentation ... In my experience it often helps a lot to meet with people in person. I did in fact one time fly to china to meet people in person with the goal to get documentation which I was not able to get over means like email and phone and this worked perfectly. But also with western companies if you visit them in person the talk can be on a different level than over email.

With the Coldfire there are people that designed it, that have put love, sweat and blood into developing it.
Joe is one of them. I would try to meet one of these people, and speak with him in person. I would tell him about your project
and with some luck he might fall in love with the idea to support you.
This will then be a complete different situation for you.

[Cyprian]

@Gunnar68080 that would be great!

[niallquinn]

TAlking of FPGA's, I wish someone could improve the ST core in include the Falcon if it's at all "do-able". Certainly the 68030 version should be possible, but then I guess add in the custom chips, and you've ran out of transistors, and their simply isn't the interest to do a core.
They come up on Ebay every now and again but for mega money, would have loved to have one at the time.

[unseenmenace]

Just spitballing here, but what I'd really love to see is a new scratch-made Atari (TOS computer) that resembles a TT (maybe a 3D printed case?) but has a new motherboard that includes as many original ICs as possible for compatibility (Yamaha soundchip, 2 x MFPs, DSP, Blitter, ACIAs etc) but has an enhanced, but backwards compatible FPGA video chip (maybe DVI output with line doubling for SD resolutions) and a much better CPU, and this 080 core sounds like an ideal choice to my mind. For me the goal would be to make a modern useable computer with as close to 100% backwards compatibility as possible with ST, STE, TT & Falcon in one machine. Yes I'd also like the moon on a stick, but imagine a modern day useable computer that could natively run the majority of TOS software!

[Cyprian]

Just spitballing here, but what I'd really love to see is a new scratch-made Atari (TOS computer) that resembles a TT (maybe a 3D printed case?) but has a new motherboard that includes as many original ICs as possible for compatibility (Yamaha soundchip, 2 x MFPs, DSP, Blitter, ACIAs etc) but has an enhanced, but backwards compatible FPGA video chip (maybe DVI output with line doubling for SD resolutions) and a much better CPU, and this 080 core sounds like an ideal choice to my mind. For me the goal would be to make a modern useable computer with as close to 100% backwards compatibility as possible with ST, STE, TT & Falcon in one machine. Yes I'd also like the moon on a stick, but imagine a modern day useable computer that could natively run the majority of TOS software!

@Wizztronics who owns complete Atari Falcon Microbox is working on that: https://www.atari-forum.com/viewtopic.p ... 39#p462939

[niallquinn]

Just spitballing here, but what I'd really love to see is a new scratch-made Atari (TOS computer) that resembles a TT (maybe a 3D printed case?) but has a new motherboard that includes as many original ICs as possible for compatibility (Yamaha soundchip, 2 x MFPs, DSP, Blitter, ACIAs etc) but has an enhanced, but backwards compatible FPGA video chip (maybe DVI output with line doubling for SD resolutions) and a much better CPU, and this 080 core sounds like an ideal choice to my mind. For me the goal would be to make a modern useable computer with as close to 100% backwards compatibility as possible with ST, STE, TT & Falcon in one machine. Yes I'd also like the moon on a stick, but imagine a modern day useable computer that could natively run the majority of TOS software!

@Wizztronics who owns complete Atari Falcon Microbox is working on that: https://www.atari-forum.com/viewtopic.p ... 39#p462939

Oooo, /me goes off to check, thanks for mentioning it.

[oregfalcon30]

If people are interested, I have about 10 brand new firebee in stock. Produced in 2023. We were going to use them for educational purposes, but the plans fell through so we have these 10 boards that are pretty much unused and brand new


Anyone interested, I can post some information

[MCal27]

If people are interested, I have about 10 brand new firebee in stock. Produced in 2023. We were going to use them for educational purposes, but the plans fell through so we have these 10 boards that are pretty much unused and brand new


Anyone interested, I can post some information

I’d be interested in more info please. I was inline to buy one a few years ago but dropped out as it was taking soo long for them to be ready for sale.

thanks, Al

[guibrush]

I can be interested too

[Mikerochip]

Same, drop me a message, post it here, etc. I'd be fairly interested, too!