Official 1.3 release?

[iss000]

Hi all, I open this issue to collect your opinions about the next official release 1.3 of Oricutron and how ready we are to make it? :) IMHO there are some points which definitely should be resolved:

1. Make Oricutron compatible with "recommended community standards". (btw, which one is actually the Oricutron's license?)

2. Reformat all sources to be consistent with the code formatting style which @pete-gordon choose and keep it persistent always. Small housekeeping if there are useless files in the repo. Try to resolve the 39 Issues.

3. Keep the master branch clean with emulation only for "standard" hardware which existed in the Oric era, focused on the stability and the portability for all supported host platforms (and adding new www, android, etc.).

4. For all newly developed extension we will use dedicated branches. I personally don't mind to have everything together, but for instance I already have OricExos and 4 more projects and if I commit them all there will be performance issues for sure. This will be more convenient for developers too - they will be able to make their own distributions when needed. As alternative is to create (who?) a real API for plugins which allows any plugin to be "switched off", so no impact on the main code performance.

What do you think?

[jedeoric]

Hello,

I think that a the release could be done.

Anyway, for the others points :

1. I think that we should write at least coding guide line a. CamelCase or underscore (Underscore is used) b. indentation : tab, space (how many) c. parenthesis : K&R, Gnu etc

2. we should have folders like : a. hardware/cpu/6502 b. hardware/io/6522 c. hardware/fdc/1793

3. for this point, we should have a standard api plugin. As you mentionned, at point 4, someone should code it. I don't want to do it, but i can port twilighte board emulation to this new API.

Anyway, i can have a look to some point if you want like travis point which is not finished, but i think that i can't switch on travis interface the repository to launch travis pipeline. I think that only @pete-gordon can do it. Or else, we should create an organisation on github (for example)

The main problem for me is that i can't test others targets system as morphos/amigaOs etc

[polluks]

At least I can test MorphOS. For OS4 I have to install the SDK.

[Dhebug]

I don't have any particular feelings about anything, but if you can all come up with a new version of Oricutron that I can install in the OSDK, I would be very happy (I'm still using a very old 1.2 version).

That being said, I feel necessary to mention that:

• None (absolutely none) of the SDL2 versions work on my machine, being the ones built by ISS on his developer site, or the ones built by Antony for his 8bit hub, or by myself. It just either explodes, or I get black screens, nothing work, so as far as I'm concerned I would like to stick to SDL 1
• I noticed the latest Oricutron were 64 bit, I don't think that brings any benefit at all, in the context of the OSDK I've made sure to keep everything compiled in x86 instead of x64, explicitly so people could keep using old versions of windows (the ones that allow using WriteDSK, etc...)
• I need a proper and complete list of changes between 1.2 and 1.3, being features, behavior changes, bug fixes, etc...
• We have to make sure it works fine for everybody, including people using different languages in windows, etc...
• I need it to work as before in regard to the shared rom files between Euphoric and Oricutron

I guess that's about it :)

[pete-gordon]

Hi folks,

Sorry i've been so quiet.

So, for information, since the 1.2 release my personal life has been much too busy for me to do any of my hobby development, so Oricutron has fallen by the wayside.

Note that a few times in the intervening years, I have thought about making an "official" 1.3 release, but one issue was that my AmigaOne died and I don't have an environment setup to build or test the OS4 version (sidenote: I have had offers of new OS4 hardware but I can't take people up on those offers when in reality I just don't have time to devote to OS4 stuff). Now, I know that OS4 is very niche and the venn diagram of people who are interested in both Oric and OS4 are very small, so it's a dumb reason not to just turn the handle and make a 1.3 release for windows, but OS4 will always be special to me as I invested a lot into it and made good friends doing so (I'm technically on the core dev team, but my last commit to the repo was a long time ago for the reasons outlined above), and I always wanted OS4 to be fully supported in Oricutron, and therefore without that I just couldn't muster up the enthusiasm to make a new release (this is a hobby that I do for fun, so it's not all about rationality. Heck the only reason Oricutron doesn't use pre-existing drivers for things like 6502, disk or AY is that the whole project was just to see if I could write my own emulator from scratch...).

I did ask if someone wanted to take over maintaining the OS4 port, but got no takers, sadly.

Anyway, the point is, you guys have my blessing to put together an official 1.3 release. I'll be sad that it won't have OS4 support on release day, but that's OK.

Once it's made, I'll update the official Oricutron download page with your builds (if I can still remember how to log in!!).

Thanks for all your help with Oricutron guys, I really appreciate it.

[pete-gordon]

BTW, I did once start a complete rewrite of Oricutron (v2), so that it would be a much neater, better code base to work from, but given that I didn't find time to even make an updated build of 1.x, you can guess how that went...

[pete-gordon]

With regard to the license question, I selected GPLv2 when I originally hosted it on Google code. My actual preference these days would be BSD license, but given that other people have contributed to the software while it was listed as GPLv2, it is probably simpler to stick with that.

[pete-gordon]

As for code formatting, my preference these days is tab indenting, aligned curly braces (as opposed to inline opening brace), but I don't have a strong preference.

If we stick with space indenting, my preference would be 4 spaces (since that's what the coding standards where I work uses).

I suggest running it all through uncrustify or so and having one commit where the only thing that changed is the formatting.

[pete-gordon]

also, my naming convention preference is for lower case with underscores, even though things_get_quite_long.

[mmuman]

I did ask if someone wanted to take over maintaining the OS4 port, but got no takers, sadly.

I'll ask on French Amiga forums just in case. As an alternative, QEMU now supports emulating the Sam460ex (someone merged my whole patchset for it), so you could try using that.

BTW, I did once start a complete rewrite of Oricutron (v2), so that it would be a much neater, better code base to work from, but given that I didn't find time to even make an updated build of 1.x, you can guess how that went...

Can't you put this in a branch so others can have a look?

My actual preference these days would be BSD license, but given that other people have contributed to the software while it was listed as GPLv2, it is probably simpler to stick with that.

Well it's still possible to switch the license, you just need to get the permission of other contributors. Anyway, a LICENSE file in the top directory with the contents of the chosen license should get GitHub happy about that.

I suggest running it all through uncrustify or so and having one commit where the only thing that changed is the formatting.

clang-format can fix the formatting as well. Both are available in Debian.

[mmuman]

None (absolutely none) of the SDL2 versions work on my machine, being the ones built by ISS on his developer site, or the ones built by Antony for his 8bit hub, or by myself. It just either explodes, or I get black screens, nothing work, so as far as I'm concerned I would like to stick to SDL 1

Hmm, on my Debian Sid it builds an runs, but I can't seem to get out of full-screen.

I noticed the latest Oricutron were 64 bit, I don't think that brings any benefit at all, in the context of the OSDK I've made sure to keep everything compiled in x86 instead of x64, explicitly so people could keep using old versions of windows (the ones that allow using WriteDSK, etc...)

It should be possible to automate building a 32bit one with mingw even on linux…

[mmuman]

Btw, if anyone wants to propose a talk at the RetroComputing devroom at FOSDEM (I'm co-chair)… or at the emulation devroom…

[pete-gordon]

I'll ask on French Amiga forums just in case. As an alternative, QEMU now supports emulating the Sam460ex (someone merged my whole patchset for it), so you could try using that.

WinUAE can also run OS4, but it isn't just a case of being able to run OS4, if I had time to devote to actually developing on OS4, I would have accepted one of the offers of free hardware...

Can't you put this in a branch so others can have a look?

No, not enough work was done to make that worth doing.

[mmuman]

We could also just cross-compile binaries automatically (like with the NetSurf toolchain, I have a patch to also builds SDL) and ask people to test them, it doesn't require a coder for this.

[mmuman]

Btw, gcc 2.95 in Haiku doesn't like the 0b11011111 in plugins/twilighte_card/oric_twilighte_board_plugin.c…

[mmuman]

Also, I get a No such file or directory on plugins/twilighte_card/oric_twilighte_board_plugin.o when building, it seems it doesn't get compiled in the proper directory. I suppose I could switch to the newer gcc anyway, it's not like it's a system library that required 2.95…

[mmuman]

I also get via.c:52: comparison is always true due to limited range of data type. which I suppose is true since a signed char will always be <=127.

[FreeFull]

Haiku is also capable of using a newer gcc, I'd recommend doing that instead of using gcc 2. gcc 2 is only there for compatibility with the old beos software.

[iss000]

... doesn't like the 0b11011111

I don't see a reason to not use the ol' good way 0xdf ;)

[polluks]

@FreeFull Indeed, gcc 2 was also a long time default on MorphOS, but the last SDK includes gcc 10.

[mmuman]

Well, some platforms still have picky compilers (thinking about Plan9 for example). Anyway, some issues are not about gcc2.

[Godzil]

@Dhebug Sadly for some OSs (Mac OS X to not name it) 64bit is the only available option nowadays, and even Microsoft is no longer selling 32bit version of windows. (Though they still support 32bit apps for now)

Even for linux support for 32bit app probably start to be scarce by default. It's not a bad thing that Oricutron build for 64bit, it should not be that difficult to have a 32bit built too.

One thing that should be done is using a CI tool like travis so binaries or test are run for each commit done on the repository, it would also allow to build "nightly" binaries if configured to, so people could test between official releases without the need to compile it themselves. It may not be possible to target all supported OSs as tool like travis only support Windows, Mac OS X and Linux, but that's still a good way to make sure that you don't build one of these target.

For the 0b prefix, there is also a good reason to not use it: it is not in the C standard. I know that some compiler do accept it, but some will not. It seems to be part of some recent C++ standard but yet, until it is accepted in the C standard (not sure it will ever) I would avoid using it.

I agree that the project should probably refactored, but maybe this should be aimed for a 2.0 release instead?

If that was up to me, I would get rid of SDL whatever the version.

@pete-gordon For the license change, there has beens one (slight) contribution from me, it does not matter to me if things are change or not. There are not that many contributors, if you really want to change it, that should not be too hard to get approval I think.

Maybe it would be a good idea to create a milestone in GitHub for the 1.3 and list and add "bug" report accordingly to what need to be done and fixed for that release to know better where things are going.

Edit: And as iss was saying it would probably be a good idea to run a pass on all the opened bugs and see which one are still relevant and which are no longer. Last time I had a look I think there were some duplicated, and trying to squash most of the still opened one before doing a new release

[polluks]

@Godzil Would you like to replace SDL by native routines?

[mmuman]

What's wrong with SDL? Apart that it's maybe slow, doesn't allow native menus and… oh well. Still it makes things easier to port to new platforms…

[pete-gordon]

I'm still hoping someone will organise a proper 1.3 release 👍