ralphb

You COPY'ed file BITMAP.asm contains an invalid Unicode char in the word "più": UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf9 in position 5103: invalid start byte (not shown without removing one except clause, though) You probably used a different encoding. So, either use the UTF-8 encoding or don't use non-ASCII chars. I don't know why the behavior is different for earlier Python versions, but my guess is that they removed some ambiguity about the encoding for text mode open().

Would it be possible for you to share the code in question? Either post a link, or mail to r@ti99.pro.

This is quite strange. Could you please try something? In file xas99.py, please comment out lines 859, 861 and 862 (should be try/except/raise) and try again on Linux. What error do you get now?

No, I'm using an F7, mostly because of its FMC and SDMMC. There's also no way I'm going to learn another SDK right now. 🙃 I'm planning to use a TI voltage regulator, though -- assuming that they'll become available again one day. I also looked at some Wifi connectivity chips by TI, but nothing beats ESP in terms of available information, tools, and community.

Well, the good news is that I'm currently preparing another demo. The bad news is that there's still no reliable source of either STM32 MCUs or voltage regulators. 😩 But at least ST announced that this might change "soon" ...

Thanks a lot, that really helps! I was looking at the register list, but didn't really notice the POS_ATTR bit (nor would I have known what it does). Edit: Also, it says ECM, which I thought does not apply to text mode.

That's great, but could you elaborate on that, e.g., by giving an example?

Matthew, I have a feature request for the F18A: Would it be possible to support more than two colors in text mode (40 and/or 80 columns)? Since almost all applications use text mode, I think it would be really nice if we could, e.g., highlight or dim text on screen or set color accents that help with understanding and navigation. I think the simplest solution (at least conceptually) would be to apply the graphics mode 1 color handling to text mode. That way, one could create a second, third, ... charset in a different color. A more advanced approach would be to mark individual rows or regions on the screen to show a different color, with a rather low limit on regions, to achieve something like a modern console with ANSI colors. Do you think something like this would be possible and worthwhile?

I've recently noticed that the copy protection of the MG Explorer disk is too good for MAME. The disk contents certainly look a little off: cassiopeia ~ > xdm99.py explorer.dsk EXPLORER : 145 used 30 free 43 KB 1S/1D 40T 9 S/T ---------------------------------------------------------------------------- MGEX22Z45 2 PROGRAM 256 B P BASAMPLE 2 PROGRAM 236 B P DIAGNOSE 60 DIS/FIX 80 15104 B 177 recs P EXP 6 DIS/FIX 80 1280 B 15 recs P LOAD 2 PROGRAM 86 B MEMEX-TEST 9 DIS/FIX 80 2048 B 24 recs P MEXP 6 DIS/FIX 80 1280 B 13 recs P MXBEXP 23 DIS/FIX 80 5632 B 65 recs P PREASSEM 2 DIS/FIX 80 256 B 3 recs P XBEXP 24 DIS/FIX 80 5888 B 68 recs P XBMEMFULL 2 DIS/VAR 163 153 B 2 recs P XBMEMOFF 3 PROGRAM 304 B XBSAMPLE 2 PROGRAM 252 B P Warning: Sector count does not match disk geometry Warning: Sector count is not multiple of 8 MAME 237 reports this error (either controller): Fatal error: Device 5.25" double density floppy drive load failed: Unable to identify the image format Not sure if it's worth analyzing, as "unprotected" versions are available. Just wanted to let you know that the emulation is not 100%. explorer.dsk

I've pushed a new plugin version that fixes the non-macro parsing. Later I'll have a look at your project, but I guess IDEA just really is a resource hog. When debugging my plugin, the sheer amount of code that is running outside the plugin is staggering.

I've just pushed a new IDEA plugin, which you can download here. Macro call arguments are now parsed correctly, which wasn't actually that difficult after I learned how it's done. The only downside of this change is that now even more code runs when editing a line. Let me know If IDEA becomes too sluggish. In addition to macro calls, I also fixed a bug that caused preprocessor commands without arguments to be shown as erroneous.

I've pushed new versions of xas99 and xga99 with support for unsigned division // and %% and logical shift operators >> and <<. I also fixed the REQU bug. I'm still working on the IDEA macro issue, which might take some time. But in the meantime, I could create a plugin that favors labels over register aliases, if you prefer.

That's odd -- I'm getting a different value if the colon is present. I'll have to check this. I'll have to do some research if a Namespace-like feature is possible, as IDEA treats all files as one project. The duplicate label, unused label, etc. checks can be implemented per file, but I'm not sure about more basic things like code completion, go-to-definition and so on. I'll check this, too.

Are you sure about that? I implemented signed multiplication and division, so that still shouldn't work. But I guess we need unsigned operations as well, and while I'm at it, shift operations as well. I hadn't added shift operators yet because >> conflicts with the hex prefix >. But I'll figure something out. EDIT: OK, that sentence made no sense before.

You're right, and it turns out that we have conflicting rules for macro arguments. Right now I define args_pp ::= ((opGA | expr) (OP_SEP (opGA | expr))*)? which means that IDEA first tries to parse a general address and then a value expression. A general address includes a register and thus a register alias, so any plain symbol that is not preceded by @ is parsed as register aliases. If I swap the rule args_pp ::= ((expr | opGA) (OP_SEP (expr | opGA))*)? then any plain symbol will be parsed as symbol and never as register alias. We never have this ambiguity outside of macro arguments, since every operand is either-or. The only solutions to this ambiguity I see right now are - live with having an error for symbols or register aliases - make register aliases syntactically different from other symbols, e.g., by prepending an unused symbol like § - use a marker like R# for register aliases only in macro arguments - analyze the macro body to figure out if symbol is value or register alias (difficult (EDIT: very difficult), since it would also need to change the parser result) Do you have a preference for a solution, besides 4?

Unfortunately that's not a very conclusive result. addrtest also uses bank switching, so it's not that this is the one cause of the problems. ramtest failing is not that big a deal, and might be a consequence of using the QI firmware IIRC. The difference between addrtest and banktest might explain why some games work and other don't, as banktest uses high-frequency bank switching. This seems like the CPLD has some issues, but it could also be timing issues caused by other hardware. I still have a few CPLDs left, so I could send you one, but this really is hit or miss.

I've just published release 3.6.0: Add -B option for fully padded binaries for xas99 and xga99 (also joins all SAVEs and banks/GROMs) Detect existing GPL header when creating MAME cart images for xas99 and xga99 Include macro calls in list file for xas99 and xga99 Add syntax highlighting, navigation and semantic renaming for macros for IDEA plugin Here are direct links to the new plugin here and the summary of changes.

So all of the listed images work on your first FinalGROM, but not on the second one? Very strange, as I don't really see a pattern here ... Have you tried my test images? addrtest1m.bin banktest1m.bin ramwrite1m.bin

Regarding MAME RPK carts, is there a way to specify the address of the first byte of the GROM binary in the layout.xml file? There might be an (unwritten?) rule that all carts must start at >6000, but I don't really see a technical reason for this.

Oh, you're right. In fact, I don't analyze macro arguments at all right now. It should be possible, though. Thankfully, I decided to do "semantic substitution", i.e., macro arguments need to be complete and valid expressions. I'm working on xdt99 right now anyway, so I'll add your request to the next release.

I've pushed a new version of xbas99.py that implements a few GitHub requests. In particular, I've added local labels within subprograms as well as an option to shorten all labels to 6 chars max so that it can be compiled with senior_falcon's compiler. I also fixed a bug when using labels and more whitespace than LIST would output. All new changes are described in this file (renamed from MANUAL.diff).

Oh, I forgot to mention, it creates a file <file>.bas or <file>.b99 on the disk. If you want to print it directly to the screen, use xbas99.py -L -p <file> instead. To print it directly from disk: xdm99.py Oregon.dsk -e OREGONTEB -o - | xbas99.py -L -p - EDIT: No dysentery?! 😄 But very cool!

Greg, that's long format, isn't it? You can use xbas99 to view that file like this xbas99.py -L -d <file> If the file is from Classic 99, you'll need to unwrap it first. You can combine both steps like this: xdm99.py -F <file> -o - | xbas99.py -L -d - There's no real detection feature, but if the output of these commands is nonsense, then the file was no BASIC program. It's a real pity that TI chose DISPLAY format for merge and long formats. Since xdm99 assumes that DISPLAY files contain text, records are separated by newlines and do not include a length byte. It's entirely possible, though, that a record contains >0A, which will break that logic. For now it hasn't been an issue for me ... EDIT: newline = >0A

I've just pushed the new xbas99 version with support for char escape codes. You can find all the information here. I wasn't sure if incorrect escape codes should be interpreted verbatim, as that would improve backwards compatibility. But on the other hand the code (and I think the logic) is much simpler without that. You can still disable the new feature (and any future ones) with the new strict option -s.

Oh, I didn't know that tool window. Yes, that might be a good idea, I'll see if I can implement it.