Compilation at Win 7 64-bit

[wieczor]

Before I'll get my devkit for ST complete and working, I wanted to make some experiments and compile some examples running them in Virtual Jag. I've downloaded devkit.zip from here: http://www.hillsoftware.com/files/atari/jaguar and was able to run some precompiled COF files, but imagine my disappointment when I try to make something from examples and got funny message that included tools won't run at 64-bit Windows... Right now I've no possiblity to install other OS - if there's a way to make it updated? Or replace it by something else.

 

I'm newbie to Jaguar (not to programming or assembler) and digging in these archives, where 90% of links are not working anymore makes me sick Most of all I'm missing well commented, self-explanatory examples introducing to any working program step-by-step... Thought that devjag can be a good start...

 

Other question:

Do I have to use C to use Remover's library? I need something that plays 8-channel mods well (as far as I know U-235 doesn't yet).

[sh3-rg]

Before I'll get my devkit for ST complete and working, I wanted to make some experiments and compile some examples running them in Virtual Jag. I've downloaded devkit.zip from here:

 

Do I have to use C to use Remover's library? I need something that plays 8-channel mods well (as far as I know U-235 doesn't yet).

 

Jagware.or is a good place to look for code examples etc. There's a thread here detailing Seb's tracker player that supports 8 channels, that's part of his Removers libs. Check it out! :0)

 

ps Got a very weird and unexpected mess on screen when I quoted your post, think I'll report that to admin to see if there's a bug in the forum software.

[GroovyBee]

Do I have to use C to use Remover's library?

You might find these a good starting point for developing in "C" :-

http://www.jagware.org/index.php?showtopic=1003

http://www.jagware.org/index.php?showtopic=1096

 

These is also the GPL source code to Duckie Egg (developed using vbcc) here :-

http://atariage.com/forums/topic/203470-duckie-egg/

[wieczor]

Yep, but I don't want to use C at this point Have to admit that I got some problems with that library - as I was able to compile and make Sinister module working with no problems I have no clue, how I should compile and use this one (Sinister doesn't support 8 channels mods). It's obviously prepared for other set of tools environment - for first, makefile is not compatible with Microsoft make added to jagdev - but I figured out it has to be Linux one . Never mind - I was thinking if I could just use source files and include them in code (using LSLs plasma example for experiments). Succeeded with Sinister, but this one is causing some problems - first - some warnings at compilation (NULL offset removed - not sure if it's severe or not) but at the end linker screams about unresolved symbol - _bcopy. I assume it should be part of any common C libraries, but as I said - I'm not using C

[LinkoVitch]

I can't speak for any of the C on jag tools out there, but I write all my ASM code (68k and RISC) under Win7, I use Make and RMAC/RLN

 

Let me know if I can help. Welcome to the wacky world of JagDev

[+CyranoJ]

pfft, Win 7 is so old.

 

Everything works on 8/8.1 64 bit too.

[wieczor]

Pfff, Win 8 is so mobile Anyway it works also at my Win 7 as well I'm using right now rmac / rln as well. In fact have both sets of tools. But it still doesn't solve problem of missing library. That _bcopy function is declared in code of Remover's sound lib as extern. Where is does come from? It's not defined within library anyway.

[ggn]

That _bcopy function is declared in code of Remover's sound lib as extern. Where is does come from? It's not defined within library anyway.

I had a quick look and bcopy is a part of the Jaguar C library (again from The Removers). Specifically string\bcopy.s. I suppose you need to take that file and include it in your project + makefile. Or just copy/paste that routine inside the source that needs it. Or replace it with a move.l (a0)+,(a1)+ loop since the bcopy implementation is very generic and covers lots of cases (but we're all dirty old people that don't care if we copy 95 or 96 bytes ).

[LinkoVitch]

I cheated and wrote my own player Really should get around to looking at the C wrapper GroovyBee wrote for it and get it included in the distribution!!

[GroovyBee]

I'm not sure if you have the latest "C" wrapper. I know I don't have your latest SE to test against so I'd hold off on any "code integration" for now.

[wieczor]

I had a quick look and bcopy is a part of the Jaguar C library (again from The Removers)

 

Aaaaahhh thanks a lot I was missing that part, now it's clear - didn't figure out that it might be needed

 

Still have problems with VJ under windows - it looks like vertical blank procedure doesn't run stable - in terms of exact syncing. It looks like it runs smoothly for 2 seconds, than is slowing down for a while and runs ok and again. Looks like kind of latency problem. It's especially visible when playing music. I had that problem with all programs using VBLANK interrupt - LSL's invitro for SV2k13 (using Sinister player) and example15 from Remover's lib. But in other thread I've seen probably youtube video when it's running perfectly. But it was running under Linux. Just was wondering if anyone had similar experience and it may be any system process to shutdown or driver to update... Or just OS to be changed

[ggn]

It might be that your PC isn't up for running VJ? To double check you could always try to run your binary with Project Tempest... although that can open another can'o'worms since it's much less compatible than VJ (but when stuff on it work, it's lightning fast).

[Shamus]

Well, there's a problem with VJ running at 60 Hz as it will run ahead of the video as it's not capable of running 60 Hz perfectly (ATM, usually it'll run ~62 or so FPS) without help. If your video card can do 60 Hz, then VJ will run perfectly in that mode.

 

I do have an idea of how to fix it, but haven't had much time to futz with it.

[wieczor]

Well problem occurs both in PAL and NTSC mode and it looks deeper than just 62 to 60 It's notebook with it's standard screen so like all LCDs it's 60Hz. Had the same results on 2 notebooks, one is P6100 (Sony Vaio), second is i5 (Lenovo) so it doesn't look like lack of CPU power anyway seems that it's affecting just part using VBL. I'll check other OS.

[wieczor]

Ok, what I realized my screen refresh rate was set to 59Hz (weird setting never seen it before) after changing it to 60, VJ VBL seems to be more stable, and what's funny - more stable in PAL mode (even if NTSC would be closer to actual refresh rate). What's funny - ALMOST ok in full screen mode (not window). Is really VBLANK clock based somehow on actual screen refresh rate? Would be at least unreasonable. Or indeed much more CPU power is needed.

 

PS. Project Tempest seems to run better at least with my program (using by now Sinister player) cause this:

 

http://www.pouet.net/prod.php?which=61367

 

is causing an error DSP read32 from 00F17000

Edited April 23, 2014 by wieczor

[Shamus]

It depends on your OpenGL settings, the refresh rate of your monitor, the phase of the moon, etc. etc.

 

In all seriousness though, if you have OpenGL set to sync with your monitor's vblank, then VJ will be locked to that rate (assuming your machine is fast enough, and the rate is close to 60 Hz). Frames are cycle based, and the wait loop at the end of the frame is where things go bad. Mainly because the system timers have only millisecond granularity, and the fact that 1000 is not evenly divisible by 60 (however, 50 *does* go evenly into 1000).

 

So the upshot is, if you *do not* have OpenGL set to sync with vblank, VJ tries its best to do 60 Hz in NTSC mode and, assuming the machine it's running on is fast enough, runs ahead by around 2 or so frames per second. VJ pretty much nails it in 50 Hz PAL mode, as the millisecond timer doesn't have a remainder to deal with (again, because 50 goes evenly into 1000). I have a pretty good idea of how to fix NTSC mode to run at the correct FPS, but just need to devote some time to it.

 

Project Tempest works great up until the moment it doesn't

[Zerosquare]

There are much more accurate timing mechanisms on Windows. Probably on Linux as well, but that's your probl... I mean, area of expertise

 

Audio can be a good sync source to, especially if you want to avoid any gaps or crackle in the sound output, and don't want to do variable, funky realtime resampling to keep audio & video in sync with each other.