ralphb

I have a slim floppy drive (with standard TI controller) that can read disks alright, but I can't initialize or write to it (but could in the past). In DM2, I get error >41 when trying to write the first byte during initialization. Does anyone have any suggestions what might cause this behavior? My first guess was the write-protect detection mechanism, but there isn't anything wrong that I can see.

Not as far as I know. A cartridge cannot provide the DSR for the disk access you would need. You'd need to hack XB and TOD to do what you want. Besides, it is very much out of scope. The FinalGROM 99 is still a cartridge, so disk operations should go to a possibly enhanced disk gadget. Introducing new technology is all fine, but for me at least it should keep the spirit of the original.

But why?

Thanks, Rasmus. It should be added, though, that reloading 1 MB from the SD card is like loading a program from floppy, i.e., it takes a while. 14 seconds, to be precise.

I finally uploaded the preliminary documentation for the FinalGROM 99: https://endlos99.github.io/finalgrom99/. You'll notice that I didn't implement System GROM mode and Cheat mode. System GROM mode seems impractical for now, as the FinalGROM doesn't initialize fast enough to catch the first GROM address write. One could probably get around this if the system GROMs are still present in the console, but this seemed like missing the point. I decided to postpone this topic for later. Cheat modes could not be implemented with the current architecture, as the bytes read from the SD card bypass the main program for efficiency. And after-load patching was also not possible, as the load is a sequential, one-shot process. I think the result wouldn't justify the necessary work. My recommendation is to patch images directly and simply use patched images as cheats. The help text system and the dump I'm going to look at now. I also wondered if I should support MBX games natively, but there are already conversions that use 32K instead, so I probably won't.

Yes, I thought about that. An SD card adapter costs between €3 and €6 on my supplier sites, which is just outrageous. Of course I can get cheap Chinese ones, but then I usually don't get a datasheet, and most certainly not an official part number. Different adapters are mechanically incompatible, so I'd have to go with the expensive ones. Plus, I need to prolong the board so that the slot protrudes a little. There is one relatively cheap Digikey adapter for €2,29 plus tax, but still, this would need additional development time.

This weekend, I received the professionally assembled FinalGROM sample, and they work beautifully! And yes, you can see the professional work. No flux gunk, like on my boards. But I already knew from my plain PCBs that I mixed up two signals, so I had to add two wires on the backside. While I fixed the design, I also added one more feature. What could possibly go wrong? Using this updated design, I already contacted two PCBA houses for a quote. The production will take up to 28 working days, though, so if everything goes according to plan, I'll have carts in early June. (The SRAM is apparently super weird -- they're either not there, or outrageously expensive. I resorted to supplying them with the ICs.) I was less lucky posting the documentation today. GitHub mangled their Pages editor, so I'll need to get an extra tool before I can publish it.

So this utility basically pads the object files and concatenates them together, observing GROMs and ORG addresses?

No, xas99 cannot do this, as SFIRST and SLAST must be known in the first pass of the assembly when the AORG is reached. You'd need several passes to solve this problem, like in xga99 (which uses up to 32 passes to solve a different problem of address size changes between passes).

Wow, thanks lucien2, I'll incorporate your code into the main branch. I don't write that much GPL, so improvement are always welcome.

I appreciate all your interest, but there's no need to stake a claim here. Just send me an email when I'm ready; I hope there won't be a long wait after that.

The OP apologized to me and said that his TI had bad VRAM. So all is well now.

The FlashROM has no restriction on filesnames, and doesn't support folders. Only the first 171 files (or rather, entries) are shown. The FinalGROM uses the filename scheme found in cartridge dumps, i.e., C, D, G files of 8 chars max. For ROM-only games, you can also use longer filenames. Folders are supported and can be nested up to a path length of 114 characters (that means at least 12 levels). Each folder, including the root folder, can hold 171 entries or folders. The 171 limit is from the screen: 19 entries per screen times 9 pages (typing 1 through 9). It could be made larger, but then the start-up times also increase unreasonably.

You probably wonder what's happening, so let me give you a short update. Hardware and software for the FinalGROM is mostly done. What you see here is the final board (never mind the color), handsoldered by me. This PCB order was only to confirm the working of the final board. About a week ago, I also ordered some assembled boards from a different supplier, also as a test. Since I've never ordered assembled boards before, I couldn't trust my KiCAD to generate a correct pick-and-place file. Should the assembled carts (due in about three weeks) work, I can put it a large order, and the fun begins. Looking at the board, you'll notice that the SD module is flipped now. This was the only way to fit it into a cart shell (well, I need to confirm that yet). But you can also solder and glue a micro-SD adapter in place, if you prefer the smaller format. The cart now has 1 MB of RAM. I'll put up the detailed specs and the manual in the next weeks.

Yes, that is correct, but it's also the behavior of the original E/A cartridge. I assembled this program . * CHECK EA5 WITH IMAGE FORMAT AORG >C000 DEF SFIRST,SLOAD,SLAST SFIRST SLOAD DATA >1111 DATA >2222 DATA >3333 DATA >4444 DATA >5555 DATA >6666 DATA >7777 DATA >8888 DATA >9999 BSS >1FF0 DATA >1111 DATA >2222 DATA >3333 DATA >4444 DATA >5555 DATA >6666 DATA >7777 DATA >8888 DATA >9999 SLAST END . with xas99 and with the original E/A SAVE utility, and they come out byte identical. The original E/A was in fact my reference, as I didn't find an explanation of the SAVE format.

Thank you, PeteE, it always makes me happy if someone finds the tools useful.

Unfortunately, this is highly unlikely. The CPLD has only a limited amount of "logic", and spending some just to support one single cartridge is unreasonable. There have been some suggestions here, like the cheat mode, but it turned out that this cannot be implemented without sacrificing the load performance, so I dropped it.

Err, just to clarify: I meant me being offline ...

Thank you, lucien2, now I understand! I didn't realize the autostarting program was run in a different context. Blanking the screen does make a lot of sense for a menu translator.

Thank you, that is what I meant. You used a different technique than I, though (see #6). Which GPL assembler did you use?

Good idea, a screenshot is enough. I'd do it myself, but I don't have your setup.

This may have been asked before, but is there a way to download entire threads or conversations? This would be highly desirable for personal backups and content access while offline (yes, that happens).

Yes, but I've been talking about cartridges all along. What I'm referring to is the byte sequence that you get when you load your object file to G>6000 and dump it to a progG.BIN that you can use as a cartridge in Classic99.

That's a nice idea, but it also eats up lots of resources. It also serves no "historical" purpose but only caters to newly developed programs. As such, I won't implement this for the release, but may evaluate this later after the dust has settled.

Thank you, Rich, but OHEADER looks like an object file. I was talking about a cartridge image.