682 replies to this topic

[john4p]

You need to select a disk with the "A"-actionbutton (not the keyboard-A...). For games with more than 1 disk you can select the 2nd disk with "Y", the 3rd disk with "B" and the 4th disk with "X".

"Few lines" represent the "widescreen-modes" 320x200 and 320x216.
These are fractionally scaled to use the full height of the Pandora's screen. Turrican I&II and Shadow of the Beast II are the only games I can think of where 320x216 is the right choice.
320x200 is usable for many more games. See the games I listed above.

"Full lines" represent the 4:3 and 5:4 "fullscreen TV" modes 320x240 and 320x256.
320x256 is also fractionally scaled so needs 750MHz and frameskip 1, too.

320x240 is the fast mode with simple doubled pixels. You can play most games at 500MHz with frameskip 0 in this mode.
It's the default mode - when you start UAE4All and just always press Enter you'll be in this mode.

The GUI could be improved, of course. But it works fine and it's not that complex.

[john4p]

Actually no 320 x 200 apps weren't letterboxed. They were displayed on CRTs, they didn't have square pixels, they were taller than they were wide. The monitors were just set with the display height to fill the monitor, they were then always 4:3. Those 320 x 200 apps were made for the NTSC market. They would only appear letterboxed on PAL monitors set for the PAL 320 x 256. People assume that everything used square pixels like an LCD, that wasn't true back then. CPS2 games were the same thing, they appear "widescreen" on todays square pixel displays but in the arcade the CRTs were adjusted to be 4:3.

That's a myth for most Amiga games. Almost all of the games using 320x200 pixels I've listed earlier were all made first and foremost for the European PAL-market. On the default Amiga-monitor those games were letterboxed. They also were letterboxed on RGB TVs.

Maybe those resolutions would be stretched on NTSC-displays into 4:3-format. But that looks horribly distorted for the games I've listed.

[DaveC]

Actually no 320 x 200 apps weren't letterboxed. They were displayed on CRTs, they didn't have square pixels, they were taller than they were wide. The monitors were just set with the display height to fill the monitor, they were then always 4:3. Those 320 x 200 apps were made for the NTSC market. They would only appear letterboxed on PAL monitors set for the PAL 320 x 256. People assume that everything used square pixels like an LCD, that wasn't true back then. CPS2 games were the same thing, they appear "widescreen" on todays square pixel displays but in the arcade the CRTs were adjusted to be 4:3.

That's a myth for most Amiga games. Almost all of the games using 320x200 pixels I've listed earlier were all made first and foremost for the European PAL-market. On the default Amiga-monitor those games were letterboxed. They also were letterboxed on RGB TVs.

Maybe those resolutions would be stretched on NTSC-displays into 4:3-format. But that looks horribly distorted for the games I've listed.

No, I owned an actual Amiga in the US, almost since its release. They were NOT letterboxed on a standard Amiga 1080 monitor (NTSC). I know, I used to use it for graphics stuff (D-paint) as well as games. All 320 x 200 stuff was fullscreen. If I got a PAL game it would chop off the bottom half of the screen as PAL was higher res (but lower freq at 50 Hz).

If you were in Europe and had you monitor set to a PAL resolution then yes the 320 x 200 stuff would be letterboxed (or mostly have a black bar on the bottom of the screen).

But joystick and keyboard do make sense: If someone wants to write text (i.e. AmigaBasic, FinalWriter, etc.) on the emulator, it would make sense being able to switch to a keyboard mode where the DPad turns into cursor keys and the buttons into Page Up, Page Down, etc. (like it is on the Pandora).
And when you switch to joystick mode, the buttons and DPad are not mapped to the Amiga keyboard, but to the joystick. The rest of the keyboard could stay like it is.

Yes but it doesn't work like that now. In keyboard mode the d-pad doesn't work to control games, neither does the action buttons. It should. Many times a game will say "press F1 to start" or something like that. Right now you can't actually do that with out switching back and forth, it is a pain. It should work like a real Amiga, the d-pad should be mapped to the joystick, mouse to nubs, and keyboard to keyboard.

Right now I came across something that says "press F6" to start. There is no way to do this in either mode, Fn+6 doesn't work, it is imposible to start it with this emu!

You need to select a disk with the "A"-actionbutton (not the keyboard-A...). For games with more than 1 disk you can select the 2nd disk with "Y", the 3rd disk with "B" and the 4th disk with "X".

"Few lines" represent the "widescreen-modes" 320x200 and 320x216.
These are fractionally scaled to use the full height of the Pandora's screen. Turrican I&II and Shadow of the Beast II are the only games I can think of where 320x216 is the right choice.
320x200 is usable for many more games. See the games I listed above.

"Full lines" represent the 4:3 and 5:4 "fullscreen TV" modes 320x240 and 320x256.
320x256 is also fractionally scaled so needs 750MHz and frameskip 1, too.

320x240 is the fast mode with simple doubled pixels. You can play most games at 500MHz with frameskip 0 in this mode.
It's the default mode - when you start UAE4All and just always press Enter you'll be in this mode.

The GUI could be improved, of course. But it works fine and it's not that complex.

And how would I know all of this? There is no documentation anywhere about these things. Right now it says to select the disk with "L". So I did that. How would I know you have to then go to "A" afterwards? As I said it is horribly counterintuitive. You need to memorize how someone else thought that it should work. Come back after awhile and you need to fumble around trying to remember how it worked again. It is really bad interface design. If the interface is going to rely on all of these different buttons at least there should be a line of text somewhere on the screen saying "press A button to put in drive 1" press B button to put in drive 2" etc.

There should also be a way to map one of the AXBY buttons to "up" on the joystick. Many platformers etc used up on the joystick to jump and it is not as good as if you have a button to do it.

Those resolution options are also confusing. Maybe not to you as you did it but to me I couldn't figure out what the hell it was.

So if I want no fractional scaling I would do what? "few lines" then 320 x 240? It looks from your description that every mode is fractionally scaled. I don't get it. Is there a reason this has to be set up every time you start the emu? That is a pain too. Why not save these options? Better yet why not put these in the other menu and have them save per game?

Like I said the menu is a mess in this emu. It needs to be totally redone from scratch.

Edited by DaveC, 05 July 2010 - 08:54 PM.

[john4p]

If you were in Europe and had you monitor set to a PAL resolution then yes the 320 x 200 stuff would be letterboxed (or mostly have a black bar on the bottom of the screen).

Yeah well, most people who had an Amiga lived in Europe and had an 1084S monitor set to PAL or had a PAL TV.
Lotus II would appear to them like this:



So yes, we in Europe are used to square pixels for these games and therefore always played them letterboxed (or with 1 huge black border at the bottom) in quasi-widescreen format.
That's the reason 320x200-games look perfectly fine for us European Amiga users if they fill a 16:10-widescreen display. Because they are in the exact same format we always knew them.

Look for Youtube-videos of e.g. Lotus II and Wings. You'll only find them in 16:10-format with square pixels, emulated or on real Amiga hardware.

I can later add a "320x200 stretched into 4:3-format (640x480)"-mode for you Americans and your non-square pixels...

There should also be a way to map one of the AXBY buttons to "up" on the joystick. Many platformers etc used up on the joystick to jump and it is not as good as if you have a button to do it.

There is! Just go to "more options" and choose control method "1" (the 2nd control method) - X is now jump, A is firebutton 1. Perfect for platformers.
If you select control method "2" (the 3rd control method) you'll have X as firebutton 1 (and A as "up"). This mode is better suited for shoot'em ups.

Dunno what control method "0" (the 1st one) is for. I only use "1" and "2".

Edited by john4p, 05 July 2010 - 09:31 PM.

[craigix]

Yeah in Europe there is no doubt those games were designed to have the borders, ever box and magazine screen shot I ever saw had them in that format too.

90% of European users used a TV too - the Amiga came with the TV cables, not monitor cables.

[GunPei2X]

90% of European users used a TV too - the Amiga came with the TV cables, not monitor cables.

Ah, the beauty of the A500's TV Modulator... glad that came as standard.

[DaveC]

If you were in Europe and had you monitor set to a PAL resolution then yes the 320 x 200 stuff would be letterboxed (or mostly have a black bar on the bottom of the screen).

Yeah well, most people who had an Amiga lived in Europe and had an 1084S monitor set to PAL or had a PAL TV.
Lotus II would appear to them like this:

So yes, we in Europe are used to square pixels for these games and therefore always played them letterboxed (or with 1 huge black border at the bottom) in quasi-widescreen format.
That's the reason 320x200-games look perfectly fine for us European Amiga users if they fill a 16:10-widescreen display. Because they are in the exact same format we always knew them.

I can later add a "320x200 stretched into 4:3-format (640x480)"-mode for you Americans and your non-square pixels...

You went out of your way to agree and say just what I did, that if you were in Europe 320 x 200 stuff was letterboxed with a black bar on the bottom.

It may have ended up that the Amiga was more popular in Europe but the Amiga originated in and sold first in the US. The Amiga 1000 came out in the US first and it was a long time until it finally got popular Europe in the form of the A500. There may have been some A1000s there but it didn't catch on because it was too expensive. The Atari-ST was crushing the Amiga there in sales due to the cheap price compared with an A1000.

I would just want rather than a "320x200 stretched into 4:3-format", a simple no fractional mode 2X double. Fractional stretching looks ugly especially done the blocky way so don't really care about it. To hell with a closer aspect when it looks so ugly. 320 x 200 doubled to 640 x 400 is fine. It seems there is more concern about aspect than image quality for some reason. There should also be a straight 1:1 mode (No stretching, text would look shit) for 640 x 400 modes that productivity apps use. Also should be a 1:1 horizontal + 2:1 vertical for 640 x 200, and a 2:1 horizontal + 1:1 vertical for 320 x 400 interlace mode if you want to be complete.

Edited by DaveC, 06 July 2010 - 05:45 AM.

[john4p]

I would just want rather than a "320x200 stretched into 4:3-format", a simple no fractional mode 2X double. Fractional stretching looks ugly especially done the blocky way so don't really care about it. To hell with a closer aspect when it looks so ugly. 320 x 200 doubled to 640 x 400 is fine.

That mode is already there - "320x240" (the default mode when you push Enter thrice at the start of the last UAE4All-version) is "pixels doubled mode". If the game only draws 320x200 pixels they get doubled to 640x400 as well as the remaining black area of 320x40 pixels gets doubled to a black area of 640x80 pixels.

In the 320x200-softstretch mode the pixels get 2.4*2.4 times as big (scaled to 768x480). So the aspect of the screen stays the same (as the displayed area gets stretched by the factor 2.4 horizontally and by the factor 2.4 vertically).
Sadly this looks hideous for most 2D games. 3D games like Hunter or Stunt Car Racer look acceptable (and are "fullspeed" at frameskip 1 as they never rendered the 3D faster than at 25fps - probably only 10-15fps - so you don't miss any visible frames if you use frameskip 1 for them).
Everything will look great when we have hardware-scaling (don't get angry - the simple doubled mode won't be removed ).

It seems there is more concern about aspect than image quality for some reason.

For us Europeans the aspect ratio is correct when we see 320x200 at 640x400. So no problem here.

There should also be a straight 1:1 mode (No stretching, text would look shit) for 640 x 400 modes that productivity apps use. Also should be a 1:1 horizontal + 2:1 vertical for 640 x 200, and a 2:1 horizontal + 1:1 vertical for 320 x 400 interlace mode if you want to be complete.

I think for these productivity apps PUAE would be more suited. UAE4All is focussed on games.

Edited by john4p, 06 July 2010 - 07:36 AM.

[john4p]

Another "pro square pixels"-reason (Thalion from the English Amiga Board explained this to me):

The Atari ST did not have 320x256- or 320x240-modes suitable for games.
Its games always have been in 320x200.
Also its PAL games.
Of course these PAL 320x200-games were designed to appear correctly on a PAL display.
So that for example circle-shaped objects appear round.
They have been designed with black borders and square pixels in mind.

(Almost) all of the previously mentioned 320x200-games were released for Atari ST and Amiga and shared the same graphics (some with improved color palette on Amiga)...

So there are (a lot of) PAL 320x200 games for Amiga which have been designed with black borders in mind.

Of course there are also some NTSC 320x200 games for Amiga which have been designed to run 4:3 fullscreen on an NTSC-display.
For example Battle Squadron NTSC and Arkanoid NTSC.
But for these games there are also PAL versions for the European market using 320x256 pixels (which also makes them superior to their NTSC counterparts as they have a 28% larger playfield displayed).

Edited by john4p, 06 July 2010 - 09:07 AM.

[john4p]

Took all the savestate-related stuff from the Nokia N900-port with Cyclone and put it into the Pandora-port of UAE4All. Everything built correct (after fiddling here and there) but resulted in a segmentation fault when trying to create a savestate.
Now I just built the N900-port itself on Pandora and tried to create a savestate => also segmentation fault.

Found out the "implementation" of save_cpu() for Cyclone doesn't seem to save all that much:

static __inline__ uae_u8 *save_cpu (int *len)
{
	return (uae_u8 *)len;
}

Now built the N900 port with "UAE M68k-core" (and without Cyclone) and savestates work.
So for Cyclone the possibility to save the CPU's state just hasn't been implemented.

Makes sense since Chui has implemented savestates for his Dingoo-port which can't utilize Cyclone.

I'll try to use the "UAE M68k-core" with our Pandora-port to get savestates working.

But seems like Cyclone&savestates won't work (for now).
(Note: notaz' PicoDrive has working savestates with Cyclone.)

Should I succeed with the UAE-core I'll then just release a version with UAE-core and savestate-support and one with Cyclone and no savestate-support.

Btw., the version with UAE-core is THE current version used on N900. Although that core doesn't use Assembler like Cyclone most games still run fullspeed at frameskip 0 if the CPU is overclocked a bit.
Also compatibility is supposed to be higher with UAE core.


About the softstretch-modes: I'll try to make the softstretch-modes changeable in the emulator so there'll be only one executable and you don't have to select one at the start.
Then I'll upload the source to Pickle's svn.

Edited by john4p, 07 July 2010 - 08:14 AM.

[jonlad1]

OMG!

John4P, that is great news!

Will the change in core have any adverse effects on speed/compatibility?

Thank you so much for your hard work. So many people will benefit!

Waiting with bated breath!!

[john4p]

Will the change in core have any adverse effects on speed/compatibility?

Yes - slower speed, but higher compatibility. Because it's slower I'll also release the Cyclone-version (without savestates).

Edited by john4p, 07 July 2010 - 09:03 AM.

[EvilDragon]

Really sounds like nice additions

It would also make sense to remove the GP2X specific configuration settings (shouldn't be hard, just comment them out)

Also, one thing that would make sense (if it isn't too hard):
Either change the way to insert disks by asking in which drive you want to insert it or make a note at the bottom of the screen where it says what button is what drive.
Nobody does ever remember that

[john4p]

^ I'll go with the note.

[silver]

Found out the "implementation" of save_cpu() for Cyclone doesn't seem to save all that much:

static __inline__ uae_u8 *save_cpu (int *len)
{
	return (uae_u8 *)len;
}

I've not looked through the code properly (either Cyclone or UAE4ALL) but it might be that UAE4ALL has an old version of Cyclone. Or the instructions for saving state for Cyclone have not been added to Uae4all.

Current version of Cyclone (http://notaz.gp2x.de/cyclone.php) , in Cyclone.h, has:

// Functions for saving and restoring state.
// CycloneUnpack() uses checkpc(), so it must be initialized.
// save_buffer must point to buffer of 128 (0x80) bytes of size.
void CyclonePack(const struct Cyclone *pcy, void *save_buffer);
void CycloneUnpack(struct Cyclone *pcy, const void *save_buffer);