LinkoVitch

Not quite sure what you are asking for here? There is a small element of multi-tasking in the engine core as it is, it shares the CPU with the Sound Engine, Mod player, Random Number Generator and Joypad reader. All of which are pretty much modules in their own rights, and run in a prioritised fashion (RNG being the lowest). There are plans to allow user code modules to be hooked in (always has been on the cards), but not gotten around to that yet, it's primary purpose is sound, and there is plenty of stuff I need to fix and optimise with that. Already started the optimisation of portions of the code whilst I ease back into it, but there is roughly 3100 lines of RISC ASM to sift through and keep working together (I've already broken it a couple of times with single line tweaks )

NecroBUMP! But actual news.. I have just released version 0.22 of the U-235 SE. Some minor fixes, I cannot remember all of which as it's been sat languishing on various disks and repo's for 4 (COUNT EM) 4 years!! wow! that's rubbish! I'm sorry, life and all that. Anyway, some minor tweaks, one significant change which hopefully resolves an issue, is that when making a call to play a sample you need to divide the playback rate by 2, this frees up a much larger range of possible synthetic frequencies needed by the mod player in the higher octaves. It's very simple, if you want to play a sample at 12kHz, you simply send the play command with the frequency 6kHz. This is a loss of frequency resolution of 1 bit at the least significant end, so should have 0 noticeable effect Anyone finds any issues please let me know here, via PM or email. Now to get started on 0.23! (still got a huge growing list of things to do!) Oh and the link: https://www.u-235.co.uk/soundengine-0-22-released/

Nope, CRY is 16bit colour, although it's a bit of a weird one The CRY 16bit colour is made up of 2 parts, one 8 bit value indicates the colour, and the other indicates the intensity of that colour. So yes there are 256 colours, but then there are 256 shades of each of those colours.

The limitation however is the Jag has only one 256 CLUT, so you can use different palettes on your 4bit images, but if they are to be displayed on screen at the same time then all the palettes need to fit within that 256 colour buffer. Plus if you have a 4 bit sprite but only used 7 colours, you will still be using 16 of the CLUT entries for your palette. So there are tradeoffs still Also according to the manual (and it makes sense) there is a performance impact for using Indexed colours as a lookup in the CLUT has to be made before rendering the pixel, although I imagine this is miniscule, but worth remembering.

You could always sell it in kit form too! Just like the original ZX80's, sure people will love gluing the components onto the board and then ranting and raving about it not working

It took me a couple of tries to get it to load in VJ also, think I had to run it in Alpine mode to get it to run eventually.

All these years in, and still learning stuff My bad, I just have an overly optimistic view of the Jaguar still it seems never as simple as you'd hope

Spinner controller is NOT analog, it's an encoder wheel type setup, and sends digital pulses down Left and Right (IIRC). You can easily identify the Jag's that have the ADC hardware, flip it over and look at the serial number, if it starts with a K then you have ADC, if it starts with an M, you DO NOT have an ADC.

Not booting the plugged in cart is quite likely a bad connection with the cart, I'd second what Mr Bear has suggested and carefully clean the port of the JagCD, If it cannot boot the cart in that slot it tries to boot a CD inserted in it. Also try cleaning the edge connector of the CD unit too.. CD's don't use the full width of the cart bus so you could possibly get into the CD BIOS no issue and even run the Odd CD game fine, but when trying a full cart if the contacts are iffy, might give you problems. It *shouldn't* be a problem, but there is actually a 2nd cart slot on a Jag CD, it has the edge connector permanently plugged into it, so it SHOULD be fine, however I guess it could be possible that if stored poorly that this too might have become oxidized and give poor contacts. Cleaning that would require disassembling your JagCD at least from the case to get access to it. I'd leave that until absolute last resort though. Good luck.

You clean your teeth with Isopropyl Alcohol or lighter fluid and a T-shirt??? weird! I just get my other half to tilt my head back and blow on them strongly :D

If you have found a bug or weirdness in that please let me know, I may be able to help, not fully setup to patch stuff fully at the moment, but it is still being worked on and any bugs found I would like to squish (working on a couple when I get a moment as it is)

Yes and no. Assembly is simpler (RISC even more so), it also removes some of the abstraction introduced by higher level languages (like variables). So if you were to start programming with assembler you would probably find it makes perfect sense, if you come from a high level language, you might be a little confused by the absence of concepts like variables, and datatypes. Talking to hardware is going to require you know "where" to write things in any language, possibly again abstracted for you by some of the languages that will present you a nice API and do a lot of the lifting for you behind closed doors. There are various simulators that will simulate a CPU and allow you to write assembly and step through it's execution, watching registers and processor flags being set etc, they are AWESOME learning and prototyping tools. I have used Easy68K myself loads when trying to figure out why a bit of code isn't doing what I thought on the jag, as it gives me much better visibility of what the 68K is doing than what I can see of the Jag's The extra CPUs in the jag can mostly be ignored until you need them, and if you have gotten your head around one CPU, picking up others isn't that difficult. I think the biggest hurdle for people with assembly is that they assume it's difficult or some kind of wizard language.. it's not.. It's just a very logical, very simplistic programming language. It may take more instructions to do the same thing, but it does the same things in smaller steps.

There is actually a German chap working on EmuTOS for the Jag at the moment too Or at least he is working to improve the GDI side of it on the Jag. I don't think he comes on here though. Might be worth having a chat with him and seeing if there is any mutually beneficial code there?

For added bonus we have free to all who get too close Patient Zero for the great European plague of 2018/2019... GazTee!! (although I am sure the rest of us are now carriers! :/) Calamity has already began too, we managed to anger a local lady when parking (sorry miss, none of us have any idea what you were saying, but we're sorry all the same), and then promptly broke the hotel lift with all of us in, between 2 floors.. YAY! ... I think ... We're all safe and sound albeit completely sleep deprived.. well I am.. hence posting on AA at 3:50 :/

That would be perfect too as I'll be showing off CJ and the Reboot guys hard work at e-Jagfest tomorrow, in Germany! Complete with a full on Um-pah brass band sound track

Mostly packed, just waiting for the rest of the Calamity Crew to get back to LinkoTowers and then we're off to the floating pub, and then GERMANY! yay

Not sure, when I am out on the planes hunting sauce I only notice the herds of HP and target those, I ignore the lesser sauces. Daddies was an OK runner up in times of extreme crisis.

Get yerself a nice squeezy bottle of HP (or HP Fruity, if you um, feel more fruity ), and revive those poor tastebuds!!

It sounds like we can never be friends... the ONLY answer is Brown!

Hmm now there's a discussion... could the Jag cook Bacon!!

Given OOP is used on embedded systems with far less ROM/RAM than the jag, nope. (and by far less I am talking 4KB of RAM and 64KB of ROM type sizes)

Would now be a bad time to say I used them as packaging material for the house move? ..... Just kidding, and they do look amazing. Sorry for the delay in all this, all of the things, all at the same time, only one likkeVitch

It can DO! Just very very thin isosceles ones :D

When I get a free moment I might have a poke see if I can add something workable.

As CJ said, MIPS is a processor architecture, NOT a 3D architecture. Yeah SGI used MIPS CPUs and also made graphics workstations.. Just like Apple made computers that did 3D based on 68K series, or PowerPC, and desktop PCs that do 3D use x86 architecture.. a CPU can do 3D, it is just maths after-all, it doesn't make it 3D hardware. https://en.wikipedia.org/wiki/MIPS_architecture If you look a bit further than "SGI did 3D Graphics using MIPS" you can see they used other technology to improve the process : https://en.wikipedia.org/wiki/Silicon_Graphics at the top of that article it mentions they used a "Geometry Engine" which was in fact a hardware device to process 3D geometries.. so you can accurately say that that was a 3D processor, it has nothing to do with MIPS.