Tursi

Not on MY Classic99! 0070 0300 limi >0002 (16) 0002 0900 0300 limi >0000 (38) 0000 0904 02E0 lwpi >83e0 (10) 83E0 > 0908 04CC clr R12 090A 23A0 coc @>0032,R14 0032 090E 1602 jne >0914 0910 0460 b @>1404 1404 Are you running a replacement ROM?

The original thread provides sufficient enlightenment. But thanks.

Is it an offset issue, or just that one word? >04CC is "CLR R12", and >0460 is "B @>" (absolute branch)... pretty big difference. >0908 is near the start of the interrupt routine, clearing the CRU base. The next instruction is supposed to test for cassette interrupt. Changing it to >0460 sounds like someone replaced the interrupt routine...

Ah ha... a case of battling bioses

I don't know what other people do, but I create separate assemblies for each memory space. When you're all done you can link the program images manually.

You could... but you have to remember it's a Z80 reading an SD card - loading the images would slow down the menu a lot. My goal in that menu was performance to get you into the game as quick as possible... But, if someone wanted to, you have 24k of ROM space to play with, and 512k of RAM during the menu execution...

I'm not entirely sure I remember. I haven't touched any of those tools since... looks like 2012? I have definitely run the Skunkboard BIOS from BJL, though... in theory it's not that hard. The Skunkboard copies the BIOS from flash to RAM for normal operation anyway, so it always runs from RAM. calc_vals does look wrong to me, too, hehe. I'd say your instinct is probably correct. The code contains absolute jumps, so if you are loading it at a different address and it's working, I assume you're changing the build address. I mean, you should find it's pretty much the same code that is actually loaded into the flash chip when programming the Skunkboard, so I guess you could try comparing against that -- or just extracting the working code and throwing this version away. I can't say what this was used for, might have just been a one-time test. What was the exception? 0x141c should still be in the initial moves... is one of the labels there mis-defined in your jaguar.inc?

The scratchpad responds to memory addresses >8000 to >83FF, so you could in theory drop 1k of RAM there. Any software that relies on the mirroring would fail, but in the unlikely instance that any was found, we could fix it.

Okay, yeah, that definitely points to the VRAM starting to go. Over at Ninerpedia there's a selection of title page images that show each VDP RAM chip individually corrupted -- if you catch catch the title page corruption matching one of them, that could tell you which chip to replace. (Or, of course, replacing them all). https://www.ninerpedia.org/index.php?title=Troubleshooting There's also the F18A upgrade - the older VGA one is harder to come by at the moment, but Matt will hopefully have the newer version in a few months. That is a plug-in replacement for the VDP that obsoletes the on-board video memory, and so bypasses the issue.

SD Card vary widely, and SD implementations usually only work with the cards that the developer had on hand to test with. Basically... I recommend trying a few other SD cards.

Version 399.032 - minor tweaks to make it build in 64-bit, but the 64 bit build is not going to be released - move the check for "pause when window inactive" to reduce slowdown - popcart CRU emulation - set VDP interrupt and alpha lock CRU in 9901 - 60fps in all places (found a place still set to 62hz) - set audio buffer to DAC level rather than assume 0 - more disk DSR sanity checks http://harmlesslion.com/software/classic99

Congratulations! Definitely take a look at your upgraded console when you have a moment, though, it should not be flakey on the title screen at all (especially because the console code doesn't even look at memory expansion, but also from experience - I ran a 32k console with a wait state switch for years). You'll probably find a cold solder joint. Well, assuming it was solid before the upgrade, of course. Failing VRAM is an increasing problem on our machines, and that would be the second guess... Of course, you can replace that too!

The UberGROM and the FinalGROM were designed with different purposes in mind. The UberGROM was never meant to be a reusable flash cartridge that you changed out daily. It was intended for permanent cartridges, to be able to reproduce older GROM carts and to create new ones. It was the first cartridge with permanently reprogrammable GROM in a single chip. So I don't see them as directly comparable. At best you can say that the FinalGROM obsoleted the need for individual cartridges, and that's probably fair. But they /were/ years apart. A few people use UberGROM for communications, which was one of the goals. It powers the XB27 suite, and that's probably its greatest use. There was also the Break Free game which used the GROM side (since Jim's PCB supports just the ROM, just the GROM, or both ). I can't remember too many other dedicated uses, but, the GROM side at least was created just so it'd be possible to make reproductions of Editor/Assembler and Extended BASIC. And a few people did that, at least! My own standpoint, though, is that it was never going to be a mass market product. I intended to aim the GROM reproductions at developers who needed them, sell the chips pre-programmed and ready for loading with GROMCFG, and make that my contribution. It all kind of blew up in my face. While I was forced to accept that and release everything to the community, there's no real need to push it. Developers who need it, have it in their toolbox.

Huh, never played that one before! 32300, level 7, Classic99

Looking fantastic

Everyone made it very clear that they hated the tools I provided.

Yep! Phoenix does sprite count and scanlines by writing those registers then re-locking the F18A.

Remember that the 32 sprites on a line has a default which is set by the user via hardware jumper. If your software relies on it working, make sure you unlock the F18A and set the limit in VR30 - otherwise it will seem to work on some machines and not on others.

You could /probably/ move the buffers inside the console and get away with it if the connector used was solid... but having it on the other side of the connector does offer potential advantages when the connection gets old.

... I had no idea...

It's not... people have used all kinds of cables over the years to replace that thing. The cable as built has buffers at each end to drive the signal, but there are no timing issues that I'm aware of. The TI's memory cycle is pretty slow. Inside the rubber is literally just a shielded ribbon cable. The big blocky "foot" that plugs into the console has buffers for that end of the cable.

I vaguely remember that...

Just use your Windows uptime...

Huh... I always assumed that when Commodore hardware and TI hardware made physical contact, mutual annihilation occurred...

I don't know if it counts as proof of concept, that's what we did for the megademo. There's already a shipped product that did it! Wish you luck though! Collabs lead to fun things.