If you really need it, there are 3 PCI slots (using a PCI riser) that you could fill with I/O cards with serial/parallel ports if you wish to.

If you want 4 joysticks, you can connect the rest to the parallel port for the games that support it, just like on classic Amigas: EXTERNAL LINK 
Tell me, because it sounds fascinating: What are you controlling that needs 5 RS232 ports and 2 parallel ports at the same time?

It's much easier to network through serial than the overhead that a bunch of ethernet ports would create, and a NatAmi could never transfer data fast enough through say 5 ethernet ports (that's too much data to send or receive) anyway to bother with it.

Actually, how could a serial port generate audio input/output into a telephone line?

I'm not too keen on using USB mice, keyboards or audio cards either.
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=35393&forum=33#657938
Prefer single items in there when I use them too. Seems hubs can be dodgy at times.

I know half a dozen people who code, and I know of one who makes games in his spare time.
And that are those who aren't on this site!

Whoa!!! Awesome news!

Many people that write software for Windows use C#.net and some middleware or a library of routines from somewhere.  It's quite a bit easier than C++ but not quite as fast.

In my spare time I'm working on a Windows and Mac port of an Amiga title using AppGameKit from the makers of DarkBasic.  The only thing I don't like about it is that you have to have a Windows box to develop for most of the platforms supported.  On my Mac I can only make Mac and iOS versions of the software.  Oh well, at least the Windows and Mac versions of AppGameKit come bundled together.

Rune Stensland wrote:

The softcore is soon Superscalar.:) Gunnar and Jens are working overtime:))

Registers:
    

How do I have to read this section? I would have expected that these are register combinations within single instructions but I frankly cannot make sense of all of them. Perhaps I have been coding too much for RISC processors with less complex address modes... :)

Could you make your tool check register dependencies between subsequent instructions? It would be pretty cool to have a rough estimate of how much faster a superscalar implementation (yay!) of the soft-cpu can be when running realistic code.

    Registers:
       

  I will improve the tool over time. Adding superscalar analysis is a good idea. I want to  modify UAE to create instruction dumps to textfiles. Then we can simulate reallife code, and do some man vs the machine messurement.
 
  2 things I want to check:
 
  Register forwarding:
  move.l a0,d0
  add.l  d2,d0
 
  Register Pipelining:
  move.l a0,d0
  add.l  d2,d1
 
  This Analysis is important for the new SoftCore.

This is a good question that went unanswered. A superscaler soft core announcement creates many questions.

1) Is the N050 core being skipped in favor of the N070 core?
2) How many parallel processing units (i.e. 2xinteger, branch, fp)?
3) How many average instructions per cycle and MHz in simulation or expected?
4) What instructions are in the core (missing 68k, CF, custom)?
5) How much of the fpga will the new soft core take up?
6) What is needed to be able to insert the core into the current Natami's fpga?

Superscaler is great news but you are leaving us hanging Rune ;).

You are doing great work! I have no recollection of how the 68k does the address mode encoding but it would probably be most useful to have statistics for each mode rather than for the registers used. From the top of my head these would be some modes to count:

dx
ax
(ax)
(ax)+
-(ax)
-(sp)
(sp)+
#xxx(ax)
(ax, dx)
#xxx
#xxx(ax, dx)

I think I hardly used anything else back in the days... :)

I want to  modify UAE to create instruction dumps to textfiles. Then we can simulate reallife code, and do some man vs the machine messurement.

That would be awesome! Imagine having a bunch of UAE users collect statistical data...

2 things I want to check:         Register forwarding:     move.l a0,d0     add.l  d2,d0         Register Pipelining:     move.l a0,d0     add.l  d2,d1

Perhaps a case like this should be observed, too:

    add.l d0,d1
    add.l d1,d2
    add.l d3,d4
    add.l d4,d5

which in a simple case of superscalarity would be processed in three cycles (1st instruction, then concurrently the 2nd and 3rd instructions, eventually 4th instruction) but could be made to execute in two cycles if the 2nd and 3rd instructions are reversed (1st and 3rd instructions concurrently, then 2nd and 4th instructions concurrently).

I couldn't come up with a better example for illustration that makes more sense. I just wanted to point out that sometimes it is not best to just pair neighbouring instructions but to change the order of instructions and then pair neighbouring instructions for parallel processing. Each pair of instructions that can be processed in parallel offers for an opportunity to change the order of instructions which may lead to overall better pairing. Of course, this makes things a lot more complex.

Tha FPGA is slow when looking at the clock rate but it can do lots of things in parallel. Thus, the best prospects for a reasonable computing speed are to aim for as much parallelity as possible. We might end up with the parallelity of present-day CPUs clocked at 1st generation pentium clock rates... :)

Yes but the new CPU might get another name. Gunnar has done over 130 checkins since January...

2) How many parallel processing units (i.e. 2xinteger, branch, fp)?

We where discussing up to 4 integer units. But 2 is more realistic.

3) How many average instructions per cycle and MHz in simulation or expected?

The core is too unfinnished yet to publish any numbers, but the peaknumbers are excellent.

4) What instructions are in the core (missing 68k, CF, custom)?

The main core will support everything. The rest of the cores will be reduced. This is the same motorola did with the Mc68060. remember P1/P2? Some instructions will pipeline, others will not.

5) How much of the fpga will the new soft core take up?

The core is compact and fast. It has been created by elite VHDL coders. :D The Integer cores is done by Jens and Gunnar and the FPU by cristoph.

6) What is needed to be able to insert the core into the current Natami's fpga?

Gunnar is testing on the cycloneIV already. Not only in the simulator.
 

Superscaler is great news but you are leaving us hanging Rune ;).

Maybe we get some more news soon..

:D

If you search for Gunnars old posts on the forum you can see some of the ideas we discussed some years ago. Some of these features has been included, and some have been left out. 020++ adressing modes that are rarely used Should we support them?

Like this one:
jsr ([xxx.l,d0])

Can be solved in old code with this:
move.l xxx.l,a0
add.w  d0,a0
jsr    (a0)

These instructions can be trapped and emulated in software. What do you think?

OK, it's good to know that things like these have been considered. I am sure that the experts will make good decisions.

020++ adressing modes that are rarely used Should we support them? These instructions can be trapped and emulated in software. What do you think?

I never used any of them and wondered why anyone would want to. Just trying to figure out whether you hit the right place in RAM with these address modes made my grey matter curdle. I wouldn't be surprised if the popular Amiga compilers never used them even once. The longest possible 68k instruction was a move with both source and destination using the most complex 020-addressing modes. IIRC the opcode could be 22 bytes long!

Personally I think that the 68k has a good history of emulating rarely used instructions using exceptions. IIRC this is the case with quite a few FPU-instructions in the 040 and the 060. Considering that this is an FPGA implementation, the modes could still be implemented later on if someone finds that they do affect execution speed. I have no idea what will happen with all the (valuable!) HDL-code once the hardware is released. If it will be published in some way, I could imagine that somebody in varsity research will have some interest in completing the implementation.

I'd say be careful about dropping instructions or leaving them to trap emulation. In your example you use an instruction that is usually often found in switch-statements (JMP instead of JSR) and emulators (where speed matters). (Maybe I misread this syntax, but would this instruction not have to be translated to
  lea xxx .l, a0
  movea.l (a0, d0 .w), a0
  jsr (a0)
Following my (old!) syntax rules the '[]' brackets mean indirect addressing, but I have noticed that e.g. the UAE monitor nowadays use a different syntax, so I'm probably wrong here. Anyway...)
Just because ancient compilers did not use these instructions it does not mean they are useless. For example one of the very few things where the x86 is superior to the 68000 is the instruction
CALL [esi + 32 bit offset]
which does not exist on a 68000, only as one of the extended addressing modes on the 68020. This is a pity because that's why you always have to jump twice when invoking object methods or library functions: JSR -offset(Ax) followed by JMP abs.l. When some while ago Gunnar asked for new instructions to add to the 68050 core these were the only ones that came to my mind:
  JMP/JSR [d16(Ax)]
and maybe also
  JMP/JSR [d8(pc, d0.s * x)]
When writing programs in assembly language I use objects with individual jump lists almost all the time, so that I personally would even prefer to replace the (non-existing) JSR -(Ax) with the equivalent short form (thus avoiding the 68020 extension word), in case that opcode bit pattern is still free (haven't checked that). So in short: don't rely on old compilers or old assembly programs. Most programs had to be written for the 68000 so they could run on an old A500 as well. In those days only few programmers dared using the new addressing modes, and only if the program would not run on an old A500 anyway (like Kevin Kralian's Apple2000 emulator).

The only advantages of such a complex instruction I am aware of are that it supposedly encodes to less bytes than two normal read instructions and that it is better readable. The disadvantage is that you lock everything for the time between two read time slots. In case each read operation triggers a burst read, this can be a significant amount of time. You could use that time for doing other things and put some instructions between the two reads. Of course, this wouldn't matter if there simply isn't anything to compute. Plus you are still free to split the instruction when there is support for both instruction.

This discussion is what I thought about when saying that this is only an FPGA implementation and things could always be added later on... :)