SV FW rev 9
Moderators: Mug UK, [ProToS], lp, moondog/.tSCc., instream, Moderator Team, Nature
SV FW rev 9
Hi!
Yesterday we added a new firmware, rev 9, to nature.atari.org. You need a JTAG cable to upgrade. The new FW contains a FIFO port register for queuing up to 56 blitter operations. The memory map has also been updated to reflect this.
Yesterday we added a new firmware, rev 9, to nature.atari.org. You need a JTAG cable to upgrade. The new FW contains a FIFO port register for queuing up to 56 blitter operations. The memory map has also been updated to reflect this.
Re: SV FW rev 9
That's great news. Can you explain what the advantage of this FIFO port register is?instream wrote:Hi!
Yesterday we added a new firmware, rev 9, to nature.atari.org. You need a JTAG cable to upgrade. The new FW contains a FIFO port register for queuing up to 56 blitter operations. The memory map has also been updated to reflect this.
And do you plan to provide an ATARI installation program for this firmware?
Re: SV FW rev 9
I assume its to improve the speed at which blits are processed.
The way it was done before was to either poll the blitter to see if it was finished or to respond to an interrupt triggered when the blitter is finished.
Both ways introduce latency/overhead. The interrupt way I guess is the preferred way but it involves responding to the interrupt so if you have many blits a lot of time would be spent in the interrupt code just dealing with the interrupt itself, not only writing new blitter commands. This cost can now (if I understand this correctly) be spread across multiple (up to 9) blitter operations instead of being a cost per single blitter operation.
The way it was done before was to either poll the blitter to see if it was finished or to respond to an interrupt triggered when the blitter is finished.
Both ways introduce latency/overhead. The interrupt way I guess is the preferred way but it involves responding to the interrupt so if you have many blits a lot of time would be spent in the interrupt code just dealing with the interrupt itself, not only writing new blitter commands. This cost can now (if I understand this correctly) be spread across multiple (up to 9) blitter operations instead of being a cost per single blitter operation.
Re: SV FW rev 9
The amount of blitter operations that can be queued is 56 (and 9 registers for each operation is written). The FIFO helps us get away from using interupts, because they were freezing the machine too often, and we couldn't find the problem despite extensive searching using oscilloscope etc. And as deez points out, the FIFO solution also is a slightly faster way to handle things, because the CPU isn't interrupted all the time.
Re: SV FW rev 9
Whats stopping you from increasing this to maybe 1000? It already mimics command buffers used by gpus but 56 sounds a bit low 

Re: SV FW rev 9
There is a very limited amount of block RAMs in the FPGA, which are used for this FIFO. Each BRAM is 2KB in size. With a 32bit data bus that gives us 512 longwords per BRAM. We would like to save the remaining BRAMs for other stuff. 

Re: SV FW rev 9
We will create a FW updater program for this version soonish.
Re: SV FW rev 9
Why not use SV Ram for that?instream wrote:There is a very limited amount of block RAMs in the FPGA, which are used for this FIFO. Each BRAM is 2KB in size. With a 32bit data bus that gives us 512 longwords per BRAM. We would like to save the remaining BRAMs for other stuff.
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)
Adam Klobukowski [adamklobukowski@gmail.com]
Adam Klobukowski [adamklobukowski@gmail.com]
Re: SV FW rev 9
Cool.instream wrote:We will create a FW updater program for this version soonish.

Re: SV FW rev 9
Well, that is of course possible, but then we would need to redesign the blitter much more.AdamK wrote:Why not use SV Ram for that?instream wrote:There is a very limited amount of block RAMs in the FPGA, which are used for this FIFO. Each BRAM is 2KB in size. With a 32bit data bus that gives us 512 longwords per BRAM. We would like to save the remaining BRAMs for other stuff.
Re: SV FW rev 9
I just saw that you already put the atari updater program onto your website. Thank you. Downloaded, programmed, rebooted, everything's fine.instream wrote: Well, that is of course possible, but then we would need to redesign the blitter much more.

BTW, programming the new firmware took 1 minute 39 seconds.
- TheNameOfTheGame
- Atari God
- Posts: 1480
- Joined: Mon Jul 23, 2012 8:57 pm
- Location: Almost Heaven, West Virginia
Re: SV FW rev 9
patjomki wrote:I just saw that you already put the atari updater program onto your website. Thank you. Downloaded, programmed, rebooted, everything's fine.instream wrote: Well, that is of course possible, but then we would need to redesign the blitter much more.
BTW, programming the new firmware took 1 minute 39 seconds.
Thanks for the head's up. Was waiting for the tool.
