Please login or register.

Login with username, password and session length
Advanced search  


Created for developers of all Amiga camps

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - SamuraiCrow

Pages: [1] 2
Announcements / Tapatalk support
« on: August 08, 2017, 09:49:22 AM »
I'm trying to add support to this forum so that it can be viewed using the Tapatalk app and similar apps that use the same plugin such as Owl.  This has the potential to speed up access to systems with limited web browser support by using a custom app.

SAGA / TinyGL ported to Vampire
« on: March 08, 2017, 08:14:40 AM »

From readme:
TinyGL is intended to be a very small implementation of a subset of
OpenGL for embedded systems or games. It is a software only
implementation. Only the main OpenGL calls are implemented. All the
calls I considered not important are simply *not implemented*.

The main strength of TinyGL is that it is fast and simple because it
has not to be exactly compatible with OpenGL. In particular, the
texture mapping and the geometrical transformations are very fast.

Programming Tutorials / C Chapter 3: Pointer variables
« on: April 26, 2016, 04:40:51 PM »
Welcome again to Chapter 3 to the tutorial that is increasingly leaning toward the title "Navigating the Warts of C Programming".  Today's issue is pointer variables.

There are several operators that define and indicate pointer operations.  Some of them are the address-of operator (notated by the unary ampersand: & ), the pointer traversal (indicated by the 2 character arrow:  -> ), the pointer dereference (indicated by the unary asterisk: * ), and the pointer definition (also indicated by the unary asterisk in another context: * ).

Let's start by allocating a pointer.  There are a number of valid ways to do that according to the 1989 ANSI/ISO standard:
  • *int varname;
  • int varname[];
  • int *varname;
  These indicate the same thing according to the standard:  a variable containing a pointer that points to an integer.

Let's discuss the first one.  Putting a unary asterisk in front of the int type is supposed to make the list of comma-separated variable names following it all pointers to the integer.  It is the rarest format and unfortunately, is so rare that many compilers didn't notice they were not supporting this part of the standard until their compilers had been in production for years!

Now for the second one.  The empty square-brackets at the end of the variable name indicate an unbounded-array.  In other words, it is a pointer to integers extending to infinity in the positive direction.  Let's call this an invitation to overrun buffers and although it just makes a pointer to an int, it is inconsistent with the purpose of a pointer to point to an item.  Avoid this syntax also.

Finally, this is a pointer definition attached to the variable definition.  This is the most common syntax.  Use it in good health.  Note that since the type is listed by itself, both integer variables and pointers to integers can be mixed together in one like of code.  It is the most flexible, most streamlined and most confusing syntax I've known in the C language... covered so far, anyway.   :P

To be continued.

Programming Tutorials / C Chapter 2: Composite and user-defined types
« on: April 18, 2016, 05:18:17 PM »
In our previous chapter, we made an indication of the typedef command's ability to define a type name as a means of keeping track of types.  One example is as follows:
Code: [Select]
typedef unsigned long ULONG;Do you notice how the ULONG type saves keystrokes?  There's ANSI C doing it's thing.

Something I didn't discuss before is the ability to "glue" multiple values together in a structure.  This is accomplished using the struct keyword.
Code: [Select]
struct record {
  WORD number;
  UWORD rank;
  ULONG score;
Do you notice how immediately after the struct code block but before the semicolon there is a variable declaration called "myrec"?  Even if you don't want to declare a global variable of a struct type, the semicolon is required even as if you did.  If that wasn't confusing enough, there's another problem having to do with creating a typedef of a struct type:
Code: [Select]
typedef struct record rec;  Now is "rec" a type name or a variable of struct record?  When using the typedef command in conjunction with a struct, typedef takes precedence so "rec" is a type name.

In order to access a member of the myrec variable, you do this to assign score a value:
Code: [Select]
myrec.score=value;  Do you see how the dot operator works on a static structure?  (By static structure, I mean that the record is a variable itself and is not pointed to by a pointer which will be chapter 3.)

There are more hangups with the use of structures in C.  Since score is a global identifier defining a location in a record structure, what happens if you try to define another structure type with a record named score or another variable named score globally?  You get an error!  That's right, member names are always global in C.  In order to avoid this from happening let's revisit our record structure definition and type definition:
Code: [Select]
typedef struct {
  WORD r_number;
  UWORD r_rank;
  ULONG r_score;
  Now there's a prefix on each member of rec to tell what record type the member name is actually a member of.  This is called a "Hungarian prefix".  There also is a type definition called "rec" but no name on the struct type.  This avoids having some variables declared as:
Code: [Select]
struct record r; and others declared as
Code: [Select]
rec z; so once again, the solution to the confusion in C is more confusion in C.  :P

Bounties / Tilemap.library
« on: August 19, 2015, 12:00:00 PM »
Step 1:  Convert ScrollingTrick sources to shared library.
Step 2:  Add BOB/VSprite support with multi-region clipping.  (This is NOT optional because the ScrollingTrick algorithm introduces a Copper seam that allows wrap around from the bottom to the top of the screen buffer to save Chip RAM.)
Step 3:  switch Copper handler to allow rainbows
Step 4:  make Amos extension as frontend and create simple examples
Step 5:  AGA version of the same
Stretch goal 1:  add TOME features like animated tile support and multi-tile Briks, then update the extension and make example AMOS codes to demonstrate the capabilities
Stretch goal 2:  CPU blitting for Fast RAM tile access and faster BOBs on 68020+ while possibly adding PowerBobs extension compatibility
Stretch goal 3:  Adapt to allow tiled dual playfield support
Stretch goal 4:  sidebar “screen” support using sprite hardware
Stretch goal 5:  Mesa version for AROS graphics card users
Stretch goal 6:  MiniGL/TinyGL version for NextGen Amiga-like systems without requiring an emulator
Stretch goal 7:  OpenGL/latest Mesa version for Mac/Linux/Windows systems (depends on stretch goal 5 or 6 being met successfully).

URL is if you want to donate on

Programming Tutorials / C Chapter 1: the basics
« on: January 27, 2015, 10:11:51 PM »
Hi everybody!

There are similarities between all structured programming languages in that they contain the same simple operations.  Since C was designed to save on the number of keystrokes when developing the Unix operating system, the 'begin' and 'end' keywords that were in common usage in Pascal were replaced by '{' and '}' respectively.  This is why C is considered the first "curly brace" language.

Simple types of data:
voidno data
inta signed whole number assigned to the biggest size supported by the architecture, in this case 32 bits
unsigned intan unsigned whole number with the same size as int but in positive direction only
floatIEEE single-precision floating point (scientific notation)
doubleIEEE double-precision floating point numbers
shorthalf the width of an int, in this case it is 16-bits
unsigned shortsame idea as unsigned int but smaller
longunsigned int by another name
unsigned longunsigned int by another name
chara single ASCII character or byte--Don't assume signed or unsigned unless you specify

An asterisk in front of a type means that it is a pointer to that type.  Pointers on Amigas are 32-bits.
Integers can be signed or unsigned so there are keywords "signed" and "unsigned" in front of them to indicate as such.

Type definitions:
Commonly used types can be assigned an alternate name using the 'typedef' keyword.  Exec.library's headers contain some common ones:

Some Exec types:
LONG32-bit integer
ULONGunsigned 32-bit integer
SHORT16-bit integer
USHORT16-bit unsigned integer
BYTE8-bit integer
UBYTE8-bit unsigned integer
APTRtypeless pointer
BPTRBCPL-style pointer (still no type associated with it)

Since 64-bit AROS and future PPC architectures are planned to support larger than 32-bit architecture, please DON'T use 'int' as a data type since on those machines the type will be promoted from 32-bit to 64-bit at compile time.  All of the Exec types can be defined using standard types but will be a consistent size only if you use the ones the OS provides.

Common standards / Standard Portable Intermediate Representation
« on: December 09, 2014, 03:07:59 PM »
After glancing through the LLVM mailing list, the search term "SPIR" was suggested as a platform-independent intermediate representation for C and OpenCL.  It looks to me as if it is based on the same backend technology as the PNaCl project started by Google for browser-based portable native apps under Chrome but without the overhead of requiring the Chrome browser.  I think this could be handy for writing a processor-neutral frontend for AROS and Arix.  I'll see if I can find any white-papers on it and report back here.  The general description is listed at the Khronos Group's webpage for it.

AmigaOS 3.x Dev / References on are placeholders?
« on: November 05, 2014, 01:15:09 PM »
Are the reference links being pasted here placeholders for autodocs or other documentation?  If not, there's an awful lot of broken links in them.  The function names aren't clickable!

AmigaOS 3.x Dev / AmiBlitz 3 syntax link
« on: October 27, 2014, 02:56:24 AM »

Programming Tutorials / C programming tutorial
« on: August 31, 2014, 03:55:43 AM »
Hi!  I am going to start tutorials and discussion here about programming in C on the Amiga at the request of RedNova on

AmigaOS 3.x Dev / Spooling polygon geometry from a disk
« on: May 19, 2014, 06:29:33 PM »
It occurred to me yesterday, that an animation file format consisting of double-buffered raw custom copper lists writing to the blitter registers would be possible.  For example, if you wanted to have a realtime non-textured polygon-rendered animation with audio, here are roughly the steps that I would use:
  • Allocate two buffers of chip RAM for the Copper lists and sample buffers, probably unified so that each buffer be 64k aligned to an even 64kbyte boundary.
  • Open two appropriate screen buffers.
  • Open the file and read the first two frames.
  • Set up a Copper-triggered interrupt to rebuffer the next frame.
  • Use a fixed copper-list header in Chip RAM to initialize the blitter window to the entire screen, set the screen registers and sprite registers, and other necessary initialization and end in a Copper jump to the copper-list buffer that has just been loaded from the disk.
  • Use a Copper interrupt on the CPU to signal when the first frame's Copper list has finished executing.
  • Read in the next frame over the top of the previous frame buffer from the file while the current frame is running.
  • When the last frame has been loaded in, close the file and disable the interrupt hook for the file reading.
  • Deallocate and shut down gracefully.

The file format would require:
  • Frames can be of variable lengths for the Copper lists but fixed lengths for the samples.
  • The audio data item should load first since it is of fixed length.
  • Little fault tolerance toward corruption of data.

Other assumptions made include:
  • Once the screen dimension window for the blitter is set for the current screen, it need not be overwritten later on in the Copper list (or if it did, it would set a return vector in a CopJmp register and call a Copper subroutine whose address would be contained in the other CopJmp vector as initialized in the Copper list header and so on).

To be continued...

I recall a former engineer which had access to the Amiga blitter design tell me that the processing of filling polygons involved a ROM image lookup containing all of the resultant bit patterns for 16-bits of input, 1 bit of carry fill input and 1 bit of inclusive/exclusive mode as a bank selector.  The outputs were 16 bits of image data and a single bit of fill carry.

The advantages of such a design in practice are that all 16-bits of pattern data plus the fill-carry can be processed in 2 bus cycles pipelined.  One to read in the inputs, and one to write the resultant outputs.  Note that the carry-fill is a register bit so it can be processed in parallel to the memory bus.

The disadvantages in modern times are that it is bus-bound and cannot be done superscalar without duplicating the ROM lookup in the chipset.  Also, 17-bit busses are rather odd to recreate in an FPGA I assume (although having the 16-bit data output and 1 bit of fill-carry output could also be recreated using 2 arrays, each for the respective sizes, with the same address numbers fed to both might work).  The lookup would be limited to a 2-stage pipeline for the same reason as that superscalar designs being impractical.

One thing I wished that could have been done on AGA but wasn't was that the blitter (including the fill mode) could have been clocked 4 times faster and buffered to use fast-page mode.  This would have meant that we'd have had a 14 MHz blitter instead of a 3.5 MHz one.  It would have been totally possible since other parts of the Alice chip had 28 MHz sections on it already.

Now, would it be practical to use such a lookup-table approach in an FPGA at all?  I assume it would take a bunch of logic units to contain the table since the memory blocks would be SRAM rather than EEPROM or flash.  Would the only way to do it be to just hog a bunch of LUs?

AROS Dev / Enhanced support for Copper on 68k?
« on: March 27, 2014, 08:09:44 AM »
I'm putting together a draft of a proposal for the AROS Copper handling functions:

I've found one issue over and above compatibility with Kickstart 3.1 that would make Copper support excel in AROS:  A CYield function or macro that would allow other Copper lists to insert their instructions before a CWait so they would be able to interleave between each other.

An example of how CYield would be useful is ScrollingTrick (on the Aminet) and its Y-Unlimited2 algorithm for tile-maps in conjunction with a static Copper rainbow.  The rainbow would change the palette registers at all the same intervals.  There is also a seam where the bitplane registers are all reset to the top of the screen buffer to save Chip RAM implemented behind the right border.  Since the interval where the seam occurs scrolls with the screen and the rainbow function doesn't, there is no way for MrgCop to know where to insert the bitplane register changes in the Copper-list that implements the rainbow unless the CWait macros in the rainbow are replaced by CYield macros.

To further complicate matters, what if there are 2 playfields of tile-maps using the Copper wrap-around trick mentioned earlier?  Then there are 2 seams offsetting at different intervals which cannot be predictably before or after one another.

The devil is in the details though.  I propose that there would have to be coordinates of start positions of each partial Copper-list for the initial CWait in each section.  (All subsequent CWait macros would be treated as atomic.)  This would allow the CYield to end one partial Copper-list and start a different one using the CNext macro at the end of the first.  The second part of the implementation would be for an enhanced MrgCop that would use a natural merge-sort or similar algorithm to merge the partial Copper-lists together.

Any developer comments before I post this to the mailing list?

Pages: [1] 2