Clues tracking down an emulator bug (San inc crack of Airheart) [message #337802] |
Sun, 19 February 2017 17:51 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Hi folks,
Any ideas where to start looking if Airheart boots and does its normal "cross-shaped" clear-screen effect, but what comes up is this (http://pasteboard.co/AnERNMDTD.png) instead of the normal Airheart logo. It also seems to just stay like that indefinitely instead of starting its demo play.
At this point, I *think* my double-hires routines are correct, but I'm not super sure of the 65c02 emulation in this emulator.
I thought I'd ask here in case those artifacts look familiar to anyone :-)
Zellyn
|
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337812 is a reply to message #337810] |
Mon, 20 February 2017 00:16 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, February 19, 2017 at 7:15:57 PM UTC-6, Zellyn wrote:
> After chatting with qkumba on twitter, I tried the prodos port (using an emulated CFFA card) and it appeared to work correctly. So, unclear. It may be the decompression routine or something.
Airheart is a BEAST. It uses every bit of memory, including AUX LC (both banks!) so if your implementation of the AUX LC, or AUX at all, is even a little off it will crash quickly either on the title screen or the moment you start the game and hit the rocket boosters. Don't feel dismayed or down-trodden, it's a challenge and an accomplishment to get this game playable. Hang in there! :D
-B
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337840 is a reply to message #337812] |
Mon, 20 February 2017 13:19 |
qkumba
Messages: 1584 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
>> After chatting with qkumba on twitter, I tried the prodos port (using an emulated CFFA card) and it appeared to work correctly. So, unclear. It may be the decompression routine or something.
The problem is in my floppy-drive code, that works in AppleWin because it's not cycle-exact.
I should have checked MAME at the time - it clearly doesn't work there.
I will fix it.
Since the "ProDOS" version works (it's really not using ProDOS at all once the game starts loading - it's all ProRWTS code), then it's not the decompression code.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337847 is a reply to message #337840] |
Mon, 20 February 2017 16:59 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, February 20, 2017 at 12:19:11 PM UTC-6, Peter Ferrie wrote:
>>> After chatting with qkumba on twitter, I tried the prodos port (using an emulated CFFA card) and it appeared to work correctly. So, unclear. It may be the decompression routine or something.
>
> The problem is in my floppy-drive code, that works in AppleWin because it's not cycle-exact.
> I should have checked MAME at the time - it clearly doesn't work there.
> I will fix it.
>
> Since the "ProDOS" version works (it's really not using ProDOS at all once the game starts loading - it's all ProRWTS code), then it's not the decompression code.
Gotta love it! Well, good luck! Sounds like you're on the right trail. Which emulator is this for, anyway?
-B
|
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337919 is a reply to message #337840] |
Tue, 21 February 2017 10:56 |
Michael AppleWin Debu
Messages: 1262 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
On Monday, February 20, 2017 at 10:19:11 AM UTC-8, Peter Ferrie wrote:
>>> After chatting with qkumba on twitter, I tried the prodos port (using an emulated CFFA card) and it appeared to work correctly. So, unclear. It may be the decompression routine or something.
>
> The problem is in my floppy-drive code, that works in AppleWin because it's not cycle-exact.
> I should have checked MAME at the time - it clearly doesn't work there.
> I will fix it.
>
> Since the "ProDOS" version works (it's really not using ProDOS at all once the game starts loading - it's all ProRWTS code), then it's not the decompression code.
Peter, before you fix this -- can you send us currently non-cycle-exact code?
i.e. We can add this to AppleWin as a test case to detect when/if the disk cycle timing emulation is fixed.
Thanks,
Michael
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337921 is a reply to message #337919] |
Tue, 21 February 2017 11:11 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, February 21, 2017 at 10:56:07 AM UTC-5, Michael AppleWin Debugger Dev wrote:
> i.e. We can add this to AppleWin as a test case to detect when/if the disk cycle timing emulation is fixed.
FYI, I'm working on a generic IIe emulator test suite. I already have the high-ram langcard-like functionality tests done (no emulators I've tested so far pass perfectly, although I'm MacOS so haven't tried AppleWin), aux-ram banking tests, softswitch-reading tests, and Cxxx-ROM banking tests. I've started in on graphics tests.
I don't yet have any disk tests -- in fact it's sort of an explicit non-goal at the moment -- but I could see adding them in the future (or accepting pull requests!). So if you can distill the problem down to a succinct description that I can implement as a read-and-then-write test, it might be a good thing to add in the future.
Later,
Zellyn
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337922 is a reply to message #337919] |
Tue, 21 February 2017 11:24 |
qkumba
Messages: 1584 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> Peter, before you fix this -- can you send us currently non-cycle-exact code?
>
> i.e. We can add this to AppleWin as a test case to detect when/if the disk cycle timing emulation is fixed.
Yes, I will extract the relevant part and send it.
The issue is that it's using too many cycles at one point and one nibble is being missed per sector. The code also did not verify the checksum, otherwise it would hang sooner.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337936 is a reply to message #337921] |
Tue, 21 February 2017 13:00 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, February 21, 2017 at 10:11:51 AM UTC-6, Zellyn wrote:
> On Tuesday, February 21, 2017 at 10:56:07 AM UTC-5, Michael AppleWin Debugger Dev wrote:
>> i.e. We can add this to AppleWin as a test case to detect when/if the disk cycle timing emulation is fixed.
>
> FYI, I'm working on a generic IIe emulator test suite. I already have the high-ram langcard-like functionality tests done (no emulators I've tested so far pass perfectly, although I'm MacOS so haven't tried AppleWin), aux-ram banking tests, softswitch-reading tests, and Cxxx-ROM banking tests. I've started in on graphics tests.
>
> I don't yet have any disk tests -- in fact it's sort of an explicit non-goal at the moment -- but I could see adding them in the future (or accepting pull requests!). So if you can distill the problem down to a succinct description that I can implement as a read-and-then-write test, it might be a good thing to add in the future.
>
> Later,
>
> Zellyn
I added JUnit stubs in Jace for this kind of thing. Curious to see what you've come up with. You can write unit tests in Jace which have actual assembler in them and it will use ACME to build the code and then run it. On the java side after plugging the code into memory it will run for the specified number of machine cycles and then assert if the result is correct.
For example:
@Test
public void testAdditionNonDecimalWithCarry() {
cpu.A = 0;
cpu.D = false;
cpu.C = 1;
assemble(" adc #1");
assertEquals("0+1 (c=1) = 2", 2, cpu.A);
assertFalse("Result is not zero", cpu.Z);
}
-B
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #337937 is a reply to message #337936] |
Tue, 21 February 2017 13:10 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, February 21, 2017 at 1:00:41 PM UTC-5, BLuRry wrote:
> I added JUnit stubs in Jace for this kind of thing. Curious to see what you've come up with. You can write unit tests in Jace which have actual assembler in them and it will use ACME to build the code and then run it. On the java side after plugging the code into memory it will run for the specified number of machine cycles and then assert if the result is correct.
For my own emulator, I did this kind of thing: For instance, here you can see a set of instructions that is assembled, then run in parallel on both my emulated 6502 and the "virtual 6502" gate-level simulation: https://github..com/zellyn/go6502/blob/master/tests/compare_ test.go#L93
I've now moved on to working to improve OpenEmulator, rather than playing with my own emulator, and I know less about testing it. I also wanted to create a generic emulator test that will help improve every emulator out there.. So currently, it's a .DSK image, built with qkumba's "Standard Delivery" loader, so that (a) it'll be fast, and (b) the disk will be mostly trailing zeros so I can transfer it quickly with ADTPro :-)
Zellyn
|
|
|
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338070 is a reply to message #338069] |
Wed, 22 February 2017 12:33 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On Wednesday, February 22, 2017 at 12:28:12 PM UTC-5, gid...@sasktel.net wrote:
> There wouldn't happen to be an old WineBottler version of Ciderpress also there per chance?
What do you need to do with CiderPress? Are you comfortable on the commandline, and if so, would applecommander do what you want?
Just curious: I've been working on my own commandline disk utility in a desultory fashion, and I'm thinking about adding a GUI by having it pop open a browser window with the UI there. Curious what functionality folks find most useful.
Zellyn
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338164 is a reply to message #338069] |
Thu, 23 February 2017 04:46 |
sicklittlemonkey
Messages: 570 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, 23 February 2017 06:28:12 UTC+13, gid...@sasktel.net wrote:
> There wouldn't happen to be an old WineBottler version of Ciderpress also there per chance?
I did happen to make one back in 2013. The links look like they might work even though I eventually deleted the containing folder from my Google Drive..
Here's the email I posted to comp.sys.apple2 - maybe someone can find the time to bottle the new version of CiderPress.
(Expanded summary of the post from the Facebook "Apple II Enthusiasts" group.)
Since WineBottler can package AppleWin for Mac OS X I presumed it would be pretty easy to make a CiderPress app, and it is. Here's a link for the version that requires Wine.app to be already installed. (Still 130MB though!)
https://docs.google.com/file/d/0B3JBd-TShLlLZzNPRjc5QWV3bDA/ edit?usp=sharing
And here's the stand-alone version with Wine.app embedded. (So you don't need WB, but it's 250MB!)
https://docs.google.com/file/d/0B3JBd-TShLlLSFhkV05PcXhRVkU/ edit?usp=sharing
For the smaller version you don't need to _use_ WineBottler, but you need Wine.app which WB installs. Get the latest WB release candidate as it installs a more recent version of Wine.app which is needed.
These have been tested working on 10.6 and 10.8. Apparently Wine.app has problems on 10.9 - read the WineBottler blog for more info if you run into problems.
Finally, I'll document what I did - just in case anyone is interested in making similar packages. It's fairly well documented in the WB documentation "Do Your Own" section, with a few caveats ...
http://winebottler.kronenberg.org/documentation
1. I didn't use the CiderPress installer. On Windows I used Dependency Walker to find CP's referenced DLLs:
http://www.dependencywalker.com/
2. Since CP has a few modules, all in the CP directory, I zipped up the contents of that folder on Windows and unzipped it to a folder on my Mac. In WB I selected the option "This is the actual program, copy it and all files that are in the same folder".
3. The "Winetricks" option is a pain to scroll through, but CP only needs comctl32 (for COMCTL32.DLL) and vcrun6sp4 (for MFC and VC DLLs). It might be better to use vcrun6sp6, but that's a 60MB separate download - something to try if anyone runs into CP GUI problems.
4. The other options are easy or optional, then clicking "Install" will bring up a dialog to choose the destination. Here I ran into a WB bug. The default directory is the one we're copying the CP executable and DLLs from, so if WB puts the resulting app there it will package that into itself recursively and hang. (The author will try to fix that in the next release.) Choose the parent folder and all is well.
Cheers,
Nick.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338192 is a reply to message #338164] |
Thu, 23 February 2017 09:19 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, February 23, 2017 at 3:46:08 AM UTC-6, sicklittlemonkey wrote:
> On Thursday, 23 February 2017 06:28:12 UTC+13, gid...@sasktel.net wrote:
>> There wouldn't happen to be an old WineBottler version of Ciderpress also there per chance?
>
> I did happen to make one back in 2013. The links look like they might work even though I eventually deleted the containing folder from my Google Drive.
>
> Here's the email I posted to comp.sys.apple2 - maybe someone can find the time to bottle the new version of CiderPress.
>
> (Expanded summary of the post from the Facebook "Apple II Enthusiasts" group.)
>
> Since WineBottler can package AppleWin for Mac OS X I presumed it would be pretty easy to make a CiderPress app, and it is. Here's a link for the version that requires Wine.app to be already installed. (Still 130MB though!)
> https://docs.google.com/file/d/0B3JBd-TShLlLZzNPRjc5QWV3bDA/ edit?usp=sharing
>
> And here's the stand-alone version with Wine.app embedded. (So you don't need WB, but it's 250MB!)
> https://docs.google.com/file/d/0B3JBd-TShLlLSFhkV05PcXhRVkU/ edit?usp=sharing
>
> For the smaller version you don't need to _use_ WineBottler, but you need Wine.app which WB installs. Get the latest WB release candidate as it installs a more recent version of Wine.app which is needed.
>
> These have been tested working on 10.6 and 10.8. Apparently Wine.app has problems on 10.9 - read the WineBottler blog for more info if you run into problems.
>
> Finally, I'll document what I did - just in case anyone is interested in making similar packages. It's fairly well documented in the WB documentation "Do Your Own" section, with a few caveats ...
> http://winebottler.kronenberg.org/documentation
>
> 1. I didn't use the CiderPress installer. On Windows I used Dependency Walker to find CP's referenced DLLs:
> http://www.dependencywalker.com/
>
> 2. Since CP has a few modules, all in the CP directory, I zipped up the contents of that folder on Windows and unzipped it to a folder on my Mac. In WB I selected the option "This is the actual program, copy it and all files that are in the same folder".
>
> 3. The "Winetricks" option is a pain to scroll through, but CP only needs comctl32 (for COMCTL32.DLL) and vcrun6sp4 (for MFC and VC DLLs). It might be better to use vcrun6sp6, but that's a 60MB separate download - something to try if anyone runs into CP GUI problems.
>
> 4. The other options are easy or optional, then clicking "Install" will bring up a dialog to choose the destination. Here I ran into a WB bug. The default directory is the one we're copying the CP executable and DLLs from, so if WB puts the resulting app there it will package that into itself recursively and hang. (The author will try to fix that in the next release.) Choose the parent folder and all is well.
>
> Cheers,
> Nick.
IMHO, it's far easier to just install the Java Runtime and use AppleCommander. It doesn't have all the fancy bells and whistles but if all you need is to manipulate a few images it's generally sufficient.
-B
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338204 is a reply to message #338192] |
Thu, 23 February 2017 11:44 |
gids.rs
Messages: 1395 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, February 23, 2017 at 8:19:10 AM UTC-6, BLuRry wrote:
> On Thursday, February 23, 2017 at 3:46:08 AM UTC-6, sicklittlemonkey wrote:
>> On Thursday, 23 February 2017 06:28:12 UTC+13, gid...@sasktel.net wrote:
>>> There wouldn't happen to be an old WineBottler version of Ciderpress also there per chance?
>>
>> I did happen to make one back in 2013. The links look like they might work even though I eventually deleted the containing folder from my Google Drive.
>>
>> Here's the email I posted to comp.sys.apple2 - maybe someone can find the time to bottle the new version of CiderPress.
>>
>> (Expanded summary of the post from the Facebook "Apple II Enthusiasts" group.)
>>
>> Since WineBottler can package AppleWin for Mac OS X I presumed it would be pretty easy to make a CiderPress app, and it is. Here's a link for the version that requires Wine.app to be already installed. (Still 130MB though!)
>> https://docs.google.com/file/d/0B3JBd-TShLlLZzNPRjc5QWV3bDA/ edit?usp=sharing
>>
>> And here's the stand-alone version with Wine.app embedded. (So you don't need WB, but it's 250MB!)
>> https://docs.google.com/file/d/0B3JBd-TShLlLSFhkV05PcXhRVkU/ edit?usp=sharing
>>
>> For the smaller version you don't need to _use_ WineBottler, but you need Wine.app which WB installs. Get the latest WB release candidate as it installs a more recent version of Wine.app which is needed.
>>
>> These have been tested working on 10.6 and 10.8. Apparently Wine.app has problems on 10.9 - read the WineBottler blog for more info if you run into problems.
>>
>> Finally, I'll document what I did - just in case anyone is interested in making similar packages. It's fairly well documented in the WB documentation "Do Your Own" section, with a few caveats ...
>> http://winebottler.kronenberg.org/documentation
>>
>> 1. I didn't use the CiderPress installer. On Windows I used Dependency Walker to find CP's referenced DLLs:
>> http://www.dependencywalker.com/
>>
>> 2. Since CP has a few modules, all in the CP directory, I zipped up the contents of that folder on Windows and unzipped it to a folder on my Mac. In WB I selected the option "This is the actual program, copy it and all files that are in the same folder".
>>
>> 3. The "Winetricks" option is a pain to scroll through, but CP only needs comctl32 (for COMCTL32.DLL) and vcrun6sp4 (for MFC and VC DLLs). It might be better to use vcrun6sp6, but that's a 60MB separate download - something to try if anyone runs into CP GUI problems.
>>
>> 4. The other options are easy or optional, then clicking "Install" will bring up a dialog to choose the destination. Here I ran into a WB bug. The default directory is the one we're copying the CP executable and DLLs from, so if WB puts the resulting app there it will package that into itself recursively and hang. (The author will try to fix that in the next release.) Choose the parent folder and all is well.
>>
>> Cheers,
>> Nick.
>
> IMHO, it's far easier to just install the Java Runtime and use AppleCommander. It doesn't have all the fancy bells and whistles but if all you need is to manipulate a few images it's generally sufficient.
>
> -B
I get too many spinning wheels and have to force quit too many times using OSX10.7.5.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338257 is a reply to message #337919] |
Thu, 23 February 2017 21:29 |
|
Originally posted by: John Brooks
On Tuesday, February 21, 2017 at 7:56:07 AM UTC-8, Michael AppleWin Debugger Dev wrote:
> On Monday, February 20, 2017 at 10:19:11 AM UTC-8, Peter Ferrie wrote:
>>>> After chatting with qkumba on twitter, I tried the prodos port (using an emulated CFFA card) and it appeared to work correctly. So, unclear. It may be the decompression routine or something.
>>
>> The problem is in my floppy-drive code, that works in AppleWin because it's not cycle-exact.
>> I should have checked MAME at the time - it clearly doesn't work there.
>> I will fix it.
>>
>> Since the "ProDOS" version works (it's really not using ProDOS at all once the game starts loading - it's all ProRWTS code), then it's not the decompression code.
>
> Peter, before you fix this -- can you send us currently non-cycle-exact code?
>
> i.e. We can add this to AppleWin as a test case to detect when/if the disk cycle timing emulation is fixed.
>
> Thanks,
> Michael
That reminds me, the ProDOS RWTS routines allow data coming in every 28 cycles which is 10% faster than normal 300RPM and the worst-case limit for a drive which is within-spec.
Ideally emulators would allow running in a config where .po & .dsk bitstreams arrive 10% faster (disk nibble every 28.8usec as a result of 5% slow writing drive + 5% fast reading drive).
Nibble & bitstream images (.nib & .edd) can arrive +5% faster and be within spec.
Allowing these drive speed variations in the emulators would likely catch more failure cases in both emulators and disk routines.
-JB
@JBrooksBSI
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338267 is a reply to message #338192] |
Fri, 24 February 2017 00:03 |
Michael AppleWin Debu
Messages: 1262 Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> far easier to just install the Java Runtime and use AppleCommander.
No offense Blurry, but at the risk of starting a flame war, you're assuming that everyone doesn't care about an insecure, bloated 50+ MB Java Run-Time Environment. I don't allow that Java crap on my Windows nor Linux boxes. On OSX I have no choice since it is needed for work and Minecraft. *sigh* I already made an exception for Jace only because I could mount .DSKs from the command line -- once you fixed it -- plus your NTSC emulation is darn good. Now if only it had proper debugger. :-)
I prefer to use SMALL programs compiled from C/C++ like God intended. ;-) i.e. All the A2TOOLS in my DSK toolchain are ~ 25K each. This means they aren't memory hogs, they are faster to load, faster to startup, they don't chew up power / battery life, I never have to worry about Java whining about updates due to some bug-flavor-of-the-month, plus I don't have to wait for the Java VM to spin up.
Hell, my Bash script to assemble an .s source file and put the .bin on a .DSK is 10K and that's only because 80% of it is comments!
More often then not, Java isn't the solution, it is the problem. I had the unfortunate misfortune of porting some of my CRC code over to Java. I wasted more time getting my makefile to build a .JAR file and run the .JAVA file then actually coding the dam thing. At least Oracle has finally come to their senses and added a proper unsigned type in Java 8. Every time I turn around programming Java I'm fighting some brain-dead language or a retarded toolchain decision. g++/llvm & .c/.cpp just work. On the bright side I can do "make jar; make java" to build and run my java programs should the need arise every again. I least I don't have to use that clusterfuck of Eclipse and/or Maven which I'm extremely happy with.
I can't stand over-engineered environments, toolchains, compilers, and IDEs.. I'm glad people have options on what toolchains they prefer because some of us like K.I.S.S.
That reminds me that I need to finish off and release my .DSK toolchain one of these days. It has some really sweet cross-platform utils to minimize the whole edit-assemble-run turn around time.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338281 is a reply to message #338267] |
Fri, 24 February 2017 07:14 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 23 Feb 2017, Michael AppleWin Debugger Dev wrote:
> I prefer to use SMALL programs compiled from C/C++ like God intended.
> ;-) i.e. All the A2TOOLS in my DSK toolchain are ~ 25K each. This
> means they aren't memory hogs, they are faster to load, faster to
> startup, they don't chew up power / battery life, I never have to worry
> about Java whining about updates due to some bug-flavor-of-the-month,
> plus I don't have to wait for the Java VM to spin up.
I write almost everything in C these days (I used QuickBasic long ago,
before free C compilers were widely available and before I learned C). I
consider it the One True Programming Language - well, apart from
assembler, of course. XD
> I can't stand over-engineered environments, toolchains, compilers, and
> IDEs. I'm glad people have options on what toolchains they prefer
> because some of us like K.I.S.S.
I don't even use an IDE. :P
> That reminds me that I need to finish off and release my .DSK toolchain
> one of these days. It has some really sweet cross-platform utils to
> minimize the whole edit-assemble-run turn around time.
This is one of the drawbacks of Ciderpress. Let's face it - sometimes a
GUI is nice, but sometimes, it just gets in the way or slows you down.
-uso.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338294 is a reply to message #338281] |
Fri, 24 February 2017 09:07 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Y'all might be interested in diskii: https://github.com/zellyn/diskii
As you can see, it's still lacking most functionality. Rather, it does precisely what I have needed it to do so far. But the structure is in place for it to grow better over time.
Alas, it is not in the "one true language" but Go is pretty good. And, I actually figured out how to get travis-ci.org to build release binaries if I tag a commit as a release: https://github.com/zellyn/diskii/releases
If you need a binary built for a platform other than linux/macos/windows 64-bit, let me know, and I'll add it.
Also, I'd be curious to know which functionality people most need - it's likely to shape the direction of future effort.
Zellyn
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338322 is a reply to message #338294] |
Fri, 24 February 2017 10:56 |
|
Originally posted by: John Brooks
On Friday, February 24, 2017 at 6:07:31 AM UTC-8, Zellyn wrote:
> Y'all might be interested in diskii: https://github.com/zellyn/diskii
>
> As you can see, it's still lacking most functionality. Rather, it does precisely what I have needed it to do so far. But the structure is in place for it to grow better over time.
>
> Alas, it is not in the "one true language" but Go is pretty good. And, I actually figured out how to get travis-ci.org to build release binaries if I tag a commit as a release: https://github.com/zellyn/diskii/releases
>
> If you need a binary built for a platform other than linux/macos/windows 64-bit, let me know, and I'll add it.
>
> Also, I'd be curious to know which functionality people most need - it's likely to shape the direction of future effort.
>
> Zellyn
Brutal Deluxe's Cadius is another good tool for Disk II manipulation:
http://brutaldeluxe.fr/products/crossdevtools/cadius/index.h tml
-JB
|
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338366 is a reply to message #338294] |
Fri, 24 February 2017 15:45 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, February 24, 2017 at 8:07:31 AM UTC-6, Zellyn wrote:
> Y'all might be interested in diskii: https://github.com/zellyn/diskii
>
> As you can see, it's still lacking most functionality. Rather, it does precisely what I have needed it to do so far. But the structure is in place for it to grow better over time.
>
> Alas, it is not in the "one true language" but Go is pretty good. And, I actually figured out how to get travis-ci.org to build release binaries if I tag a commit as a release: https://github.com/zellyn/diskii/releases
>
> If you need a binary built for a platform other than linux/macos/windows 64-bit, let me know, and I'll add it.
>
> Also, I'd be curious to know which functionality people most need - it's likely to shape the direction of future effort.
>
> Zellyn
travis-ci is awesome. I use it for a few things, including Jace, Outlaw Editor (for Laweless legends and Ancient Legengs), and other open source stuff I do for work.
-B
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338376 is a reply to message #338267] |
Fri, 24 February 2017 17:56 |
gids.rs
Messages: 1395 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, February 23, 2017 at 11:03:05 PM UTC-6, Michael AppleWin Debugger Dev wrote:
>> far easier to just install the Java Runtime and use AppleCommander.
>
> No offense Blurry, but at the risk of starting a flame war, you're assuming that everyone doesn't care about an insecure, bloated 50+ MB Java Run-Time Environment.
Uhm! compared to a 554 Mb wine bottled version of Cider Press, 50 Mb looks pretty good.
The PC version of CP including all drivers is only 7 Mb.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338392 is a reply to message #338376] |
Fri, 24 February 2017 21:37 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, February 24, 2017 at 4:56:57 PM UTC-6, gid...@sasktel.net wrote:
> On Thursday, February 23, 2017 at 11:03:05 PM UTC-6, Michael AppleWin Debugger Dev wrote:
>>> far easier to just install the Java Runtime and use AppleCommander.
>>
>> No offense Blurry, but at the risk of starting a flame war, you're assuming that everyone doesn't care about an insecure, bloated 50+ MB Java Run-Time Environment.
>
>
> Uhm! compared to a 554 Mb wine bottled version of Cider Press, 50 Mb looks pretty good.
>
> The PC version of CP including all drivers is only 7 Mb.
It's really adorable people say this about Java but when prompted to install YET ANOTHER version of the Dot Net framework they don't even bat an eye. It's the same kind of tech, different name. The only big mistake was keeping it as a browser plugin but that's going away. As a program environment it's more than sufficient. Tell you what, you let me know when you've ported AppleWin to Linux and Mac OSX and I'll eat my hat and stop using Java for anything. :P
-B
|
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338396 is a reply to message #338393] |
Sat, 25 February 2017 00:09 |
BLuRry
Messages: 489 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, February 24, 2017 at 9:01:59 PM UTC-6, Richard Thiebaud wrote:
> On 2/24/2017 9:37 PM, BLuRry wrote:
>> ell you what, you let me know when you've ported AppleWin to Linux and Mac OSX and I'll eat my hat and stop using Java for anything. :P
>
> Applewin runs fine under Wine in Linux or Mac.
No, I mean a native port that doesn't require an emulation of an entire operating system. The point I'm trying to make is that installing Java is far less of a hassle for running programs written in Java than it is to run Windows programs after first setting up Wine. The reality is that thanks to good package managers this is all totally moot:
Install the latest Java version on mac with homebrew:
brew cask install java --force
Install wine:
brew install wine
So now after you do that you can do whatever you want. If you are trying to deal with multiple java versions, I recommend using jenv on mac as it takes care of the messy environment variables. Wine isn't as much a concern as long as you're happy with the defaults.
I would caution you that apps run under wine look like a$$ on a retina screen; it was a primary reason I just stopped bothering with it not to mention that the more complex programs still don't work at all, sadly.
-B
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338444 is a reply to message #338396] |
Sat, 25 February 2017 19:42 |
Richard Thiebaud
Messages: 222 Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 02/25/2017 12:09 AM, BLuRry wrote:
> On Friday, February 24, 2017 at 9:01:59 PM UTC-6, Richard Thiebaud wrote:
>> On 2/24/2017 9:37 PM, BLuRry wrote:
>>> ell you what, you let me know when you've ported AppleWin to Linux and Mac OSX and I'll eat my hat and stop using Java for anything. :P
>>
>> Applewin runs fine under Wine in Linux or Mac.
>
> No, I mean a native port that doesn't require an emulation of an entire operating system. The point I'm trying to make is that installing Java is far less of a hassle for running programs written in Java than it is to run Windows programs after first setting up Wine. The reality is that thanks to good package managers this is all totally moot:
>
> Install the latest Java version on mac with homebrew:
> brew cask install java --force
>
> Install wine:
> brew install wine
>
> So now after you do that you can do whatever you want. If you are trying to deal with multiple java versions, I recommend using jenv on mac as it takes care of the messy environment variables. Wine isn't as much a concern as long as you're happy with the defaults.
>
> I would caution you that apps run under wine look like a$$ on a retina screen; it was a primary reason I just stopped bothering with it not to mention that the more complex programs still don't work at all, sadly.
>
> -B
>
>
Not all apps. Applewin runs well for me.
|
|
|
Re: Clues tracking down an emulator bug (San inc crack of Airheart) [message #338445 is a reply to message #338396] |
Sat, 25 February 2017 19:48 |
Richard Thiebaud
Messages: 222 Registered: May 2013
Karma: 0
|
Senior Member |
|
|
On 02/25/2017 12:09 AM, BLuRry wrote:
> On Friday, February 24, 2017 at 9:01:59 PM UTC-6, Richard Thiebaud wrote:
>> On 2/24/2017 9:37 PM, BLuRry wrote:
>>> ell you what, you let me know when you've ported AppleWin to Linux and Mac OSX and I'll eat my hat and stop using Java for anything. :P
>>
>> Applewin runs fine under Wine in Linux or Mac.
>
> No, I mean a native port that doesn't require an emulation of an entire operating system. The point I'm trying to make is that installing Java is far less of a hassle for running programs written in Java than it is to run Windows programs after first setting up Wine. The reality is that thanks to good package managers this is all totally moot:
>
> Install the latest Java version on mac with homebrew:
> brew cask install java --force
>
> Install wine:
> brew install wine
>
> So now after you do that you can do whatever you want. If you are trying to deal with multiple java versions, I recommend using jenv on mac as it takes care of the messy environment variables. Wine isn't as much a concern as long as you're happy with the defaults.
>
> I would caution you that apps run under wine look like a$$ on a retina screen; it was a primary reason I just stopped bothering with it not to mention that the more complex programs still don't work at all, sadly.
>
> -B
>
>
Or Linapple
|
|
|