exxos's Atari, Amiga & retro forum

What we REALLY need is someone to get the full 68000 signals implemented on one of these plethora of boosters, so we can have an Atari version someday.

sporniket wrote: 07 Feb 2022 10:03 And a bit of chûnibyô in my case (I have hidden xHDL powers waiting to be awaken, that will allow me -someday- to write a 64/128-bits multi-core compatible with the legacy 32 bits ISA of the 68k family :D )

Right. In that case, after you have built the 24-bit palette with 64 HW sprites shifter board, you can do the Atari 68060+SIMD booster! :lol:

mrbombermillzy wrote: 07 Feb 2022 10:18 What we REALLY need is someone to get the full 68000 signals implemented on one of these plethora of boosters, so we can have an Atari version someday.

You have this in the TF536. Or did you mean something else?

terriblefire wrote: 07 Feb 2022 11:58

mrbombermillzy wrote: 07 Feb 2022 10:18 What we REALLY need is someone to get the full 68000 signals implemented on one of these plethora of boosters, so we can have an Atari version someday.

You have this in the TF536. Or did you mean something else?

Well, I meant the MC68000 based boosters really.
It would be great to have such high speed 'plug in' solution on a plain 68000. Would save lots of effort patching code that is 020-060 incompatible.
Would just have to deal with badly written system specific timing bugs then.

But generally, the more boosters available for Atari, the better, I say! :)

(I'm particularly hoping the Buffee will fit the bill here).

mrbombermillzy wrote: 07 Feb 2022 12:22 Well, I meant the MC68000 based boosters really.
It would be great to have such high speed 'plug in' solution on a plain 68000.

My SEC booster has run up to 75MHz on a real 68000. Problem is the cost of SRAM to keep up making the end price point rather large. It's why I haven't done much with it over the past year.

@exxos both you and @terriblefire are both to be commended for the efforts in this regard.

Is the SRAM issue due to the current world shortage, or was it always this much?

mrbombermillzy wrote: 07 Feb 2022 13:24 Is the SRAM issue due to the current world shortage, or was it always this much?

Just expensive.. was like £22 a pop (need 2 or 4 chips) now its like £50 a pop. Just do not have time to build and assemble a lot of this stuff for low quantities. But really this is getting off topic anyway.

Getting back on topic...

mrbombermillzy wrote: 07 Feb 2022 08:36 This seems to be a personal vendetta. There was a similar video a while back.

Either that, or all the other V4 users havent noticed the 30% games not working, or randomly crashing of code all over the place. (Not sure they can cover up or explain away the problems to that degree :lol: ).

There arent many V4s out there AFAIK. Its just beta testers who paid of early versions of the board. Which is fair enough I suppose.

I mention this as something to look for having been verified as fixed before making a purchase.

terriblefire wrote: 07 Feb 2022 13:33 Getting back on topic...

mrbombermillzy wrote: 07 Feb 2022 08:36 This seems to be a personal vendetta. There was a similar video a while back.

Either that, or all the other V4 users havent noticed the 30% games not working, or randomly crashing of code all over the place. (Not sure they can cover up or explain away the problems to that degree :lol: ).

There arent many V4s out there AFAIK. Its just beta testers who paid of early versions of the board. Which is fair enough I suppose.

I mention this as something to look for having been verified as fixed before making a purchase.

Well, anything is possible, I suppose. (The Pentium 2 when it came out had a bug where it couldn't do addition IIRC) and that wasn't a small team.

As far as I am aware, the majority of problems (and Beta testing) on the V4 is the adaptation to ApolloOS fork not being completely finished and/or wrong settings in WHDLoad for games.

I will admit not having ever used or tested one, and the V4 core probably isn't perfect, but branching errors look like a massive oversight to me. Unless it's a specific pattern of the (as shown in the vid) NOPs and specific writes (one quick one normal) which bring on the error. Otherwise, this would be completely unstable with lots of code.

I'm sure there will be an uproar if this problem is actually true with whatever number of V4 owners there are.

EDIT: Also, I'll address the white elephant in the room: I'm well aware of how much 'tension' there is between the Apollo team and various members on this board. I certainly am not wanting to be some sort of inbetween target board, for any sort of inter personal issues, so I will just leave it at that. :)

mrbombermillzy wrote: 07 Feb 2022 14:45 ... Unless its a specific pattern of the (as shown in the vid) NOPs and specific writes (one quick one normal) which bring on the error. Otherwise, this would be completely unstable with lots of code.

What he shows there is tracing/single stepping (not "real" runtime) behaviour.
With the trace flag active, m68k triggers an exception after each instruction that brings you back to the debugger, providing single stepping facility. This not working is certainly annoying for developers that are used to use this feature, but doesn't do any harm to "normal" users.

If what he shows would be runtime behaviour the machine probably wouldn't even come up.

mfro wrote: 07 Feb 2022 14:58 What he shows there is tracing/single stepping (not "real" runtime) behaviour.
With the trace flag active, m68k triggers an exception after each instruction that brings you back to the debugger, providing single stepping facility. This not working is certainly annoying for developers that are used to use this feature, but doesn't do any harm to "normal" users.

If what he shows would be runtime behaviour the machine probably wouldn't even come up.

There are apps/games that use trace mode to decrypt blocks of code on the fly as a copy protect mechanism. Those might fail.