FPGA Replay Board

[ChaosLord]

As I recall the PAL color modulation is responsible for some of the blurring. Some C64 emulator has this blur mode. And it certinly improves the picture beauty.

What is this "PAL color modulation" of which you speak?

[ChaosLord]

Gawd... what a waste of good alcohol, much better to immerse ones self in it...

:laughing:

[ChaosLord]

You misunderstand what I was describing. I was describing a purely software solution similar to a JIT (just in time compiler): loadseg() the binary, run a function to decode and process instructions up until the first potential branch, insert a breakpoint, jump into the (possibly modified) instruction stream. Repeat.

*No* hardware support is needed for this.

You make it sound very very very easy.

If it is that easy then why couldn't Elbox get it working at high speed on their Dragon?

What do you do about games that don't use LoadSeg() ?

[ChaosLord]

Ok so start the tracer in the kickstart.

But how can the JIT tracing work inside of interrupts?

[ChaosLord]

Maybe CED v4.2 requires all 020+ instructions and addressing modes?

The FPGA CPU is missing some features, yes?

[ChaosLord]

Could you give some concrete examples of what you would realistically want to do on a 68k Amiga that requires more than 128 Mb RAM?

Gfx. Games.

[ChaosLord]

Instruction sequences that involves some kind of looping can be optimized to identify those in the instruction queue. And performing them directly with logic gates with way less clock cycles per operation.

Sadly, there is no way of actually doing that using current FPGA technology.

You could realtime analyze the instruction sequences but there is no way to reconfigure the FPGA in realtime.  In fact it cannot be reconfigured at all while it is in use.

Hopefully this will all become possible 10-20 years from now.

[ChaosLord]

Facebook, ummmm, not thanks, not everyone like FB. I won't be following along on FB, that's for sure. I don't have an account and don't intend on getting one.
:hammer:

+20

[ChaosLord]

There are really games on the Amiga that run too quick if you have an EC020 faster than 14mhz? I thought everything was tied to the vertical blank, so the speed only changes depending on whether you're running in 50hz or 60hz.

All properly coded games are tied to the vertical blank.  Not just on Amiga but all other systems too.

Any game that fails to run on a faster CPU has a tragically awful bug.

If a game uses software timing loops then there is no way for us to fix that at the hardware level.  You would need to disassemble the buggy code and fix it.  a zillion hours of work for each game. Yuck.

If a game forgets to call WaitBlit() then there is no way for us to fix that at the hardware level.  You would need to disassemble the buggy code and fix it.  a zillion hours of work for each game. Yuck.

I actually committed the above bug once.  It was just purely by accident that it happened during a code rewrite.  But a playtester reported it to me and I declared an emergency and fixed it immediately.  So the public never saw the bug.


If a game bangs on hardware registers too quickly on fast CPUs then... AHA!
There is a sneaky way to fix that.  Just make the Amiga's hardware registers respond faster and then everything will work great!

This banging regs to fast problem happens a lot when banging Paula.  It isn't like its intuitive to know that you hafta wait a certain amount of time between pokes.  Its a really annoying problem.

It has plagued the Amiga continuously since the beginning of time.

I remember when the 030 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

I remember when the 040 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

I remember when the 060 first came out, various modplayers would not work right anymore.  We had to wait for updated versions.

So anyway whoever is working on the Paula softcore, all you hafta do is rig it so that code will work, even if the code "pokes to fast".

If you can implement that then dozens of programs will suddenly start working on faster systems.

[ChaosLord]

@MikeJ

Is the FPGA chip in the FPGA Replay fast enough to generate a 1280x1024x32bit @ 60fps display?

Does it already do that?
Or is it something you could try to squeeze in with some hardcore optimized code magic?

Such a mode would burn 314MB per second of bandwidth just to show the display.

What is the theoretical maximum bandwidth of your memory chips?

How much actual bandwidth are you actually able to get out of the system so far?

I realize that the "theoretical maximum" and the "real life attainable" numbers will be wildly different, as they are with Natami.

I am asking these questions because I want to write a game that maxes out your hardware.  And I think that I will be stuck using 640x512x32-bit mode.

[ChaosLord]

Why 32 bit ? Isn't 24 more than enough ?
Just curious... I don't plan on going above 16 bit with my petty programming

Visually 24 is just as good as 32 since they are the exact same thing visually.

But the cpu processes 32-bits much more easily than 24.  Sometimes some gfx need to be drawn by the cpu (calculated fx).

[ChaosLord]

Such resolution is problematic with VGA monitors. But my RTG module supports scan doubling to upscale 640x512 to 1280x1024 which is SXGA native resolution.

I have displayed 640x512 @50 hz on many CRT monitors.  I donno if those same monitors will display it @60 hz but I just assume they will.  

I would prefer 640x512 @60 hz but Classic Amigas won't do that unless you add a pc gfx card.

I could, for a lot of additional work, laboriously go thru and chop off 32 pixels from all the GUI screens and all the game levels. in order lower the game resolution to 640x480.  Would there be any advantages to making the game run in 640x480 instead of 640x512?

[ChaosLord]

I am running PAL/NTSC broadcast spec on the output for testing - not in the Amiga core yet.
This would give you 720x488/60 (interlaced) or 720x576/50(interlaced).
The horizontal visible is maybe 700 so 640 x 512 is probably ok.
I also run 576P50 which is 720x576/50 on each field, which looks great. Any modern TV takes this over DVI/HDMI.

/Mike

There are a lot of old games which run in 640x512.  Will they be 100% correctly viewable on the Replay board when connected to a modern TV over DVI/HDMI?


I am not really clear if they will display right or if they would appear in the upperleft corner of the display and have the top and left flow off the screen in an incredibly annoying manner.  (Just like I have seen a ton of million$ PC gamez do when connected to my modern HDMI TV).

Good luck, keep up the good work.  I am planning to use every single byte of RAM on the Replay + 060 board.

[ChaosLord]

@Platon42

Did you change ISPs at some point in the past but did not update the config in your Email software?

If you are a subscriber of ISP B but still trying to use ISP A email server then they could block you.

Just an idea.

[ChaosLord]

Does this mean I have to throw away my PS/2 ports to get USB? :huh:

PS/2 is way better.  No way am I getting rid of them.  All my stuff is PS/2 and PS/2 is better for mouse and keyboard (which are required).  USB is only better for nonrequired type things like my external 2TB drives and cameras and mp3 players and things.

Anyway I would rather have both PS/2 and USB.

Sorry for ranting

Are the PS/2 ports real PS/2 ports?  Like the ones on my Core i5 box?

I was once upon a time 100% going to buy one (once the 060 card came out and was verified working correctly) but I am currently at 93% chance.

@Platon42
Does this mean FPGA Arcade will gain some superduper awesome USB support in the near future? :hammer: