Upcoming Jaguar Game Drive Cartridge

[+CyranoJ]

Holy crap. The read result changes depending on how many nops I put before the read...

 

move.l (a0),a0 ; Get current address
move.l (a1),a1 ; Get error address

gives different results to

nop
move.l (a0),a0 ; Get current address
move.l (a1),a1 ; Get error address

Not sure if this is related to the address of the 68k instruction, the relative CPU / GPU cycle offsets, or what? What I do know is, it scares the hell out of me.

 

Can anyone make this sound any saner?

 

If this is happening I'd say you have missed a .long or .phrase somewhere, or are possibly using an older version of RMAC or RLN.

 

Another potential cause could be exectution time for the instruction (although I have never seen this, except when writing to the OLP) - eg: MOVE.L #$12345678,<GPUaddress> can cause problems, but MOVE.L #$12345678,d0 MOVE.L d0,<GPUaddress> works.

 

Could you modify the CDBios pointer update routine to also put the pointer in main ram around $3000-ish, where the BIOS normally sits? or even at $2400 where the (now useless) TOC data is?

[SainT]

Is your memory move instruction setting A1 high to get the MSW first and then A1 low for the LSW? Some 68K instructions do it LSW first and then MSW which the GPU latching RAM scheme won't like.

The read order is low address then high address according to the docs... which I assume is like f03000 then f03002, which makes sense for big endian. I think things like -(an) or possibly movem change the order of reading of the two halves of the longword. I forget, it's been a while! However, that is retail bios code... and moves to and from GPU ram function correctly elsewhere.

 

I like the thought though. It seems to be the high order byte / word in general which gets corrupted. Although, that said, it sometimes just reads entirely the wrong address.

 

I don't understand if this is even a vaguely known problem I haven't seen any mention of it anywhere. I can't help but think the interrupt generation is buggering things somehow. But then again, thinking about it, I was finding similar weird things were happening before I'd even started the GPU.... or enabled interrupts. Gah...

[SainT]

If this is happening I'd say you have missed a .long or .phrase somewhere, or are possibly using an older version of RMAC or RLN.

Another potential cause could be exectution time for the instruction (although I have never seen this, except when writing to the OLP) - eg: MOVE.L #$12345678,<GPUaddress> can cause problems, but MOVE.L #$12345678,d0 MOVE.L d0,<GPUaddress> works.

 

Could you modify the CDBios pointer update routine to also put the pointer in main ram around $3000-ish, where the BIOS normally sits? or even at $2400 where the (now useless) TOC data is?

There doesn't appear to be any alignment issues. The code is loading up and running fine in the GPU, it's just the CPU side which is behaving oddly when reading from the GPU local ram... Plus I can effect software behaviour by changing the interrupt strobe! That cannot be compiler or alignment related...

 

Writing also appears to be fine, btw, it's just reading which seems to bugger up. Which is bizarre. My code basically mimics the CD bios GPU code, so I don't see why this shouldn't work.... I'm sure other code on the jag must read from the GPU local ram space??

[+CyranoJ]

There doesn't appear to be any alignment issues. The code is loading up and running fine in the GPU, it's just the CPU side which is behaving oddly when reading from the GPU local ram... Plus I can effect software behaviour by changing the interrupt strobe! That cannot be compiler or alignment related...

 

Writing also appears to be fine, btw, it's just reading which seems to bugger up. Which is bizarre. My code basically mimics the CD bios GPU code, so I don't see why this shouldn't work.... I'm sure other code on the jag must read from the GPU local ram space??

 

Yeah, my API does it a LOT (and so do most of the ports)

 

Does the interrupt modify the pointer?

[SainT]

Yeah, my API does it a LOT (and so do most of the ports)

 

Does the interrupt modify the pointer?

Yep, it's the current read pointer, so it gets modified per interrupt and polled on the 68k for progress testing. The weird thing is, if I add something like --

 

wait:

move.l G_CTRL,d0

lsr d0

bcc .wait

 

Before reading from GPU ram, it seems to work just fine! Even if the GPU is already running and I don't touch the go bit. However this code isn't present anywhere in the bios, so it should not be required... I don't want to add workarounds for what appears to be an evil problem.

[GroovyBee]

Have you set the endianess of the data in G_END e.g. BIG_PIX

[+CyranoJ]

I'd be inclined to fix it and just say that it's blind luck the original works at all.

 

Wouldn't be the first bug in the CDbios *cough*swapcd*cough*

[VladR]

There doesn't appear to be any alignment issues. The code is loading up and running fine in the GPU, it's just the CPU side which is behaving oddly when reading from the GPU local ram... Plus I can effect software behaviour by changing the interrupt strobe! That cannot be compiler or alignment related...

 

Writing also appears to be fine, btw, it's just reading which seems to bugger up. Which is bizarre.

You, yourself, acknowledge it merely does not appear, but you don't really know, as there's a behavior that needs to be discovered first. Well, by you, anyway...

Depending on the total number of dependencies / behaviors (whatever they might be), one of them *might* be dependent on alignment.

 

Trust me, all issues on jaguar, once you discover, test and confirm the HW behavior, make sense.

 

Which is bizarre.

I've noticed from this thread, multiple times, your confusion about bizarre HW / SW bugs and/or issues in jag's dev environment. How exactly did you manage to miss all those articles about jaguar's dev environment ?

 

I don't want to add workarounds for what appears to be an evil problem.

Well, then don't. I guess, that's the end of SD cart, then ? Your choice.

 

If I didn't create workarounds for every bizarre issue I've encountered in coding my 3D GPU engine, I wouldn't get past rotating cube, and forget about 60 fps, or doing clipping (or any feature, really). There were over a dozen, well I stopped counting after that...

 

I'm not telling you to burn time by trying to figure out why this particular problem happens. But, I can give you the advice on what worked for me every time I encountered a perfectly legal code (down to a single assembler instruction) that just didn't do what it was supposed to:

1. Set aside a timeframe you are willing to burn with debugging

2. When stage 1's deadline passes, implement a workaround and move on

 

In this particular example, I'd just write from GPU to main RAM (though, I think I know exactly what's going on there - you'll just have to excuse me for avoiding the shitstorm that ensues in this forum section every time I attempt making technical explanations), but usually, I simply burn the time in debugging. My documented discoveries of such bizarre jaguar behaviors span several pages in my source code and I love to add more to that list (though, admittedly, it's increasingly rare for me to encounter such new bizarre behaviors at this point).

[SainT]

You, yourself, acknowledge it merely does not appear, but you don't really know, as there's a behavior that needs to be discovered first. Well, by you, anyway...

Depending on the total number of dependencies / behaviors (whatever they might be), one of them *might* be dependent on alignment.

 

Trust me, all issues on jaguar, once you discover, test and confirm the HW behavior, make sense.

 

 

I've noticed from this thread, multiple times, your confusion about bizarre HW / SW bugs and/or issues in jag's dev environment. How exactly did you manage to miss all those articles about jaguar's dev environment ?

 

 

Well, then don't. I guess, that's the end of SD cart, then ? Your choice.

 

If I didn't create workarounds for every bizarre issue I've encountered in coding my 3D GPU engine, I wouldn't get past rotating cube, and forget about 60 fps, or doing clipping (or any feature, really). There were over a dozen, well I stopped counting after that...

 

I'm not telling you to burn time by trying to figure out why this particular problem happens. But, I can give you the advice on what worked for me every time I encountered a perfectly legal code (down to a single assembler instruction) that just didn't do what it was supposed to:

1. Set aside a timeframe you are willing to burn with debugging

2. When stage 1's deadline passes, implement a workaround and move on

 

In this particular example, I'd just write from GPU to main RAM (though, I think I know exactly what's going on there - you'll just have to excuse me for avoiding the shitstorm that ensues in this forum section every time I attempt making technical explanations), but usually, I simply burn the time in debugging. My documented discoveries of such bizarre jaguar behaviors span several pages in my source code and I love to add more to that list (though, admittedly, it's increasingly rare for me to encounter such new bizarre behaviors at this point).

Ok, let me rephrase, there are NO alignment issues. As I keep reiterating, changing the behaviour of the hardware affects the behaviour of the software. I am working on developing HARDWARE, not software, as you are. Actions of the hardware can adversely affect stability of the system. Only the inexperienced developer takes your attitude of just blindly applying workarounds without fully understanding the problem. If you do this there is every chance the issue will bite you in the ass later.

 

The thought that code just works by luck in the existing bios certainly has passed by mind. My gut feeling is that there is some synchronisation issue between GPU and CPU, and I'm trying to figure out how interrupts affect this.

[+CyranoJ]

The thought that code just works by luck in the existing bios certainly has passed by mind. My gut feeling is that there is some synchronisation issue between GPU and CPU, and I'm trying to figure out how interrupts affect this.

 

Is your code for the SD transfer taking the same time as the CD transfer did, or are you 'running fast' ? Maybe limit to 150k/sec or 300k/sec and spinlock until time to release?

[VladR]

Ok, let me rephrase, there are NO alignment issues. As I keep reiterating, changing the behaviour of the hardware affects the behaviour of the software. I am working on developing HARDWARE, not software, as you are. Actions of the hardware can adversely affect stability of the system. Only the inexperienced developer takes your attitude of just blindly applying workarounds without fully understanding the problem. If you do this there is every chance the issue will bite you in the ass later.

You have clearly misunderstood the portion where I explained that every single mysterious / bizarre issue on jag eventually makes sense, once you take your time to investigate it thoroughly.

 

 

Only the inexperienced developer takes your attitude of just blindly applying workarounds without fully understanding the problem. If you do this there is every chance the issue will bite you in the ass later.

I could write a very technical paragraph here, but it's clear it would fall on deaf ears, given your current level of troubleshooting skills.

 

I'm glad you feel better, though - by taking the unwarranted knocks at me It's typically quite revealing of the character...

Edited April 20, 2018 by VladR

[blipsqueak]

VladR, your input could surely be helpful but your tone was very condescending... You assert that the Jag arch just makes sense eventually. Sure, but what about your workarounds? Why did you need them? I think simply posting "My gut feeling is that there is some synchronisation issue between GPU and CPU, and I'm trying to figure out how interrupts affect this." without all the other stuff would have been much more helpful.

 

No trolling intended. SainT has an awesome project in the works. Some more inspirational help would probably work better.

[aminor00]

You have clearly misunderstood the portion where I explained that every single mysterious / bizarre issue on jag eventually makes sense, once you take your time to investigate it thoroughly.

 

 

[emoji38]

I could write a very technical paragraph here, but it's clear it would fall on deaf ears, given your current level of troubleshooting skills.

 

I'm glad you feel better, though - by taking the unwarranted knocks at me It's typically quite revealing of the character...

There have already been some extremely technical posts written both by Saint and others trying to help.

 

If you think you know what's happening then why don't you go ahead and post a technical explanation. I'm sure it would be appreciated if it helps.

 

Sent from my SM-G930F using Tapatalk

[Welshworrier]

So SainT is working in the nano/pico second domain, VladR is working in the microsecond domain.

 

He obviously understands edge conditions, races, reflection etc. You should listen.

[VladR]

VladR, your input could surely be helpful but your tone was very condescending... You assert that the Jag arch just makes sense eventually. Sure, but what about your workarounds? Why did you need them? I think simply posting "My gut feeling is that there is some synchronisation issue between GPU and CPU, and I'm trying to figure out how interrupts affect this." without all the other stuff would have been much more helpful.

Crap. I apologize for the tone, if that's how it came across. That was not the intention at all

 

I know it's a very lame excuse, and feel free to laugh at it, but English is not my first language (I speak 5 languages).

 

If you think you know what's happening then why don't you go ahead and post a technical explanation. I'm sure it would be appreciated if it helps.

Oh, I actually do in this particular case. Unfortunately, every single time I start explaining my technical findings in jaguar subforums (in 8-bit section, it's possible to have such discussions), a shitstorm ensues, as certain characters start spinning sh*t in 10 directions, disregarding the technical reality, mocking me like we're in kindergarten (and we're all roughly in the 40-50 age bracket here), thus killing every possible ounce of my motivation to waste energy on such explanation.

 

 

 

Again, my sincere apologies for the thread misdirection and/or misunderstandings to saint, carry on as usual guys, I'll just go back to DSP audio integration to my 3D engine and ignore this thread for few weeks...

[+CyranoJ]

Are you capable of making a post without saying 'my 3D engine' lol

[sh3-rg]

If you guys do a secret Santa, hot tip for whoever gets Vladr:

 

 

 

Edited April 20, 2018 by sh3-rg

[aminor00]

Oh, I actually do in this particular case. Unfortunately, every single time I start explaining my technical findings in jaguar subforums (in 8-bit section, it's possible to have such discussions), a shitstorm ensues, as certain characters start spinning sh*t in 10 directions, disregarding the technical reality, mocking me like we're in kindergarten (and we're all roughly in the 40-50 age bracket here), thus killing every possible ounce of my motivation to waste energy on such explanation.

 

I was enjoying "watching" the real technical work going on and Saint's request for help really opened up a side of the development process that I hadn't appreciated was there. I'm not technical in the way that you, Saint and others here are but I can understand the fundamentals of what is being discussed and I find it fascinating.

 

Ultimately, the Jag SD card will open up the Jag market a bit more, providing an easy way to get the efforts of developers, such as you, onto more consoles. Sharing a bit of your knowledge here really also helps you, in the long term. Please reconsider and maybe write that technical paragraph. I would certainly appreciate reading it.

[SainT]

Crap. I apologize for the tone, if that's how it came across. That was not the intention at all

 

I know it's a very lame excuse, and feel free to laugh at it, but English is not my first language (I speak 5 languages).

 

Oh, I actually do in this particular case. Unfortunately, every single time I start explaining my technical findings in jaguar subforums (in 8-bit section, it's possible to have such discussions), a shitstorm ensues, as certain characters start spinning sh*t in 10 directions, disregarding the technical reality, mocking me like we're in kindergarten (and we're all roughly in the 40-50 age bracket here), thus killing every possible ounce of my motivation to waste energy on such explanation.

 

 

 

Again, my sincere apologies for the thread misdirection and/or misunderstandings to saint, carry on as usual guys, I'll just go back to DSP audio integration to my 3D engine and ignore this thread for few weeks...

 

No worries, English is a language, especially when written, which can be taken the wrong way by even the most proficient of users. I will always be restrained in my replies, however I don't "take any shit" as they say. I've been around too long for that.

 

Please feel free to chip in with any information which might be of use, the above comments about latching of the GPU RAM and order of 16bit word reads for instance is something I had not thought of, and has put some other thoughts in my head. I had to do the same thing when reading 32bit registers on my hardware, so I can appreciate what's going on at a level which might give me some ideas.

 

Giving actual information, whether of use, right or wrong, will always be taken kindly by me.

 

And I'm not sure what --

 

"I could write a very technical paragraph here, but it's clear it would fall on deaf ears, given your current level of troubleshooting skills."

 

is supposed to mean. I've just spent about 50+ hours tracking down what turned out to be a "feature" of the DMA hardware of a microcontroller which required a few nano-seconds of delay on lowering the slave select of the SPI controller before starting the transfer otherwise you randomly get a corrupt byte about every 5-10 megabytes.

 

So, to be honest, I'd put my troubleshooting abilities right up there. And as I say, please feel free to and any technical detail you can, I am unaware of anything you have contributed in this area, and with the Jaguar, I am always keen to have more information.

Edited April 20, 2018 by SainT

[SainT]

On 4/20/2018 at 7:46 AM, CyranoJ said:

 

Is your code for the SD transfer taking the same time as the CD transfer did, or are you 'running fast' ? Maybe limit to 150k/sec or 300k/sec and spinlock until time to release?

 

Its about the same atm. So around 340k/sec. Although the pattern of interrupts will be a bit different due to the handshaking, etc, which I use with the hardware. I had thought along the same lines, ie. interrupt happening too soon after the previous, etc... but I limited the interrupts to every 2048 cycles (a scanline and a bit) without change in behavior.

 

Probably an idea to revisit....

Edited October 25, 2019 by SainT

[LinkoVitch]

It sounds like one of those magical joyous Jag bugs :/ hope you get it resolved. I wish I could offer some concrete solution, alas my JRISC experience has been purely in the DSP realm and copying to the DSP RAM, not reading from.

 

But I had a thought.

 

As you are reading from the internal RAM of the GPU, and the GPU is still running, IIRC the SRAM in the GPU isn't dual ported, so the GPU will be changing addresses of the RAM whilst the 68K is trying to read from it (potentially). Might it be worth trying to have the GPU write out the data you are attempting to fetch into main RAM so that the 68K can read it (or perhaps the OP line buffer if you want it as fast as possible and maybe some pretty lights ). If it's for progress counter, perhaps write out progress once ever 10/100 iterations, so it's not wasting time waiting for main RAM?

 

Should give you a nice stable output from the code without having to pause the GPU each time you want an update.

 

HTH

[SainT]

Yeah, another thought I've had also. I've tried waiting for the IMASK bit to be clear before reading just to be sure it's not in an interrupt, but no joy. The actual access to the GPU RAM is via a bus controller which arbitrates access, so (in theory) it shouldn't allow multiple access.

 

I really want to avoid writing out values to main RAM from the GPU simply because I'm afraid I've broken something at a hardware level, and I've not seen any problems until I've started messing with interrupts. But that said, I've not tried to read data from the GPU local RAM until now either...

 

Getting crap read back from the GPU when reading from local RAM cannot be "normal", otherwise people like CyranoJ would have seen it before. I've not had to go out of my way to find this issue...

[+CyranoJ]

Actually, what Linko says could be true.

 

The 68k will read the 32 bit address from the GPU in 16 bit access. So, the bus controller could lock it for one, let the GPU update, then lock it for the 2nd. The only time I've used interrupts on the GPU is to pass data into it, which wouldn't matter due to semaphore locking on the slower CPU.

 

*EDIT*

 

On top of this, there are only a handful of CD titles. If you test them all and they work... *shrug* ?

[Shamus]

Just to throw in my two bits...

 

I've done a fair bit of wading thru the CD BIOS in my attempts to get it working with VJ, and I can tell you, if it works, it's because of lucky circumstances. They do absolutely NO message passing between the 68K and the DSP when reading from the CD--it's all tied to 68K instruction timing as far as I have seen. Which blows my mind, because by that time, they surely had some people there who understood multi-CPU synchronization issues, yet they *chose* to write it so that it depended the 68K's timing (which would also explain why it doesn't work 100% of the time).

[SainT]

Hmm, getting closer to what's going on -- the GPU seems to have hung. The go bit is still set, but due to a load of logging in there, I've noticed my interrupt routine is being called without the IMASK bit being set, and without any of my pending interrupt bits set. Not quite sure how this is possible...

 

Ultimately though, it seems if you read from the GPU while it is hung (or possibly stopped also, this was one of my original assumptions) then the fetch unit misbehaves.