ralphb

Thanks for the suggestion, but unfortunately that didn't help. Looking at the BASIC line editor code (around G>2A4F) in TI Intern, I thought that >830d, which stores the repeat speed counter, might be the key (no pun intended) -- but nope, setting it to 0 before leaving doesn't do anything. I guess I'm messing with scratchpad RAM in a way I shouldn't ... Thierry states that key repetition is handled outside the SCAN routine. I'll try to reproduce it in an emulator and debug why this happens.

Alas, when I shorten my program, the issue disappears. But does the above behavior ring a bell with someone? I think I saw it before with some erroneous programs ...

I have a self-written assembly routine that I execute from either BASIC (in different ways). The routine waits for a key press before terminating itself, like this: . li r0, >05ff mov r0, @>8374 clr r0 wait_key: movb r0, @gplst lwpi gplws ; gpl r11 already saved bl @scan lwpi ws movb @gplst, r1 coc @h_2000, r1 ; new key pressed? jne wait_key . This works, but when I return to BASIC, the cursor starts auto-repeating spaces, and doesn't react to any key presses except for FCTN-=. Are there any flags/values I need to reset before returning?

Yes, I wrote LIMI >8300 instead of LWPI >8300, but this sequence of LIMI 0 LWPI ws is so common I rarely look at it. The missing LWPI caused the test program and thus the DSRLNK to run at >83e0, which caused havoc with the actual >83e0 part. I took me several hours to find the bug. The spaces are fine, as xas99 is more tolerant than E/A. EDIT: clarification

Yes, my versions work with BL instead of BLWP, and symbols are case insensitive. The missing symbols like PAB_OPEN are just somewhere, so this is not the bug ...

Thanks for the offer again, I'd pick it up, but I made some progress by finding the bug in the test program. Do you notice something about this code? . start: limi 0 limi >8300 test1: li r0, >3000 li r1, pab_open li r2, pab_open_end - pab_open bl @vmbw mov @c_3009, @>8356 bl @dsrlnk data 8 ; ... . After I fixed my test program, my DSRLNK is suddenly working. I shouldn't code for that long ...

OK, now it's working ... I used just a word for NAMSTO, so it got overwritten by the other variables and the device/file would not be found. Finally! A working DSRLNK.

Stuart, thanks for the Bagnaresi code, but there are some undefined symbols: . HAA FLGPTR NAMSTO SAVLEN SAVPAB SAVVER SAVENT SAVCRU SAV8A . HAA I can guess, but where should the others be? Inside the upper workspace, or just somewhere?

Ugh, I tried that, but lost patience. It starts alright for the first three or so loop iterations within the TIFC, but it's just one bad breakpoint and BOOM! I would never foist this on you.

Excellent! Thank you, Lee!

Those are some good points, but the entire routine is running in User WS, with only the jump using GPL WS. You can see that I only modify R9 and R12. I didn't know about FAC restauration, but this does not cause my endless loop. The NOP is only temporary, but you're right about the sbo that should be a sbz. Unfortunately, all this doesn't really explain why my DSRLNK doesn't work. Does the peripheral need more data in the FAC area besides >8354 and >8356?

I've noticed that the static version of the DSRLNK provided by xdt99, which I cobbled together from Tim's version, doesn't work at all. . My attempt to fix the MG DSRLNK wasn't really successful, and I also couldn't find your code. Which section has it? Despite all these versions, I also tried to write my own DSRLNK, but just for DSR ROM so far. The code to transfer execution to the peripheral looks like . ; found DSR entry li r1, 1 mov r1, @>83e2 ; 1 in gpl r1 mov r3, @>8354 ; pointer to start of device name a r3, r5 mov r5, @>8356 ; pointer to '.' mov r12, @>83d0 ; copy of CRU address mov *r6, @>83d2 ; next DSR chain entry mov @2(r6), @>83f2 ; target address in gpl r9 mov r12, @>83f8 ; r12 in gpl r12 lwpi >83e0 bl *r9 nop lwpi >8300 sbo 0 rt . Unfortunately, when I run this, the TI gets stuck in an endless loop within [email protected]>04DE->05A0, which is GPL FMT?! Am I missing any values that are required for correct initialization?

Sorry for not seeing this question earlier ... Just enable RAM or GRAM (by putting R or G into the fourth byte) and see if you can write to the cart space. If you're not running on the FinalGROM 99, the RAM/GRAM information will be ignored, so you cannot modify values in cart space.

About ten years ago, I signed up for the OmniScan SDK, which even required signing an NDA. My idea was to create a BASIC "language" that would run after the raw recognition to remove the most obvious errors. For each letter on the page, OmniScan creates a list of potential glyphs, together with their probabilities. In theory, you could select those glyphs with the highest probability that made sense according to a BASIC grammar. To distinguish variables, say A0$ from AO$, you'd need even more heuristics. All in all, this seemed too time-consuming to me, so it never went anywhere.

I give up.

Back on topic, Thierry does explain that MEMEN* might not go high between parts of two different instructions. His example is . LOOP MOV @>2000,R0 JMP LOOP . where the writing of R0 and the fetching of the JMP opcode happens in the same MEMEN* cycle. So it might be just as you said, Stuart. I certainly learned something today.

Just for your information, you can also use xdt99 to create a disk image: . xdm99.py -X SSSD work.dsk -a yourfile.obj -f disfix80 -n YOURFILE/O . which means to create a SS/SD disk image (-X), add your file (-a) in DIS/FIX 80 format (-f) and given name (-n). But Classic99 doesn't use disks natively, so you can also use . xdm99.py -T yourfile.obj -9 --ti-names . which creates a so-called TIFILES file (-T) with reduced header (-9 for Classic99 or v9t9 emulators) and TI-compatible name (--ti-names). You could even put both commands into a batch file, so you won't have to type them each time you want to assemble.

Bingo. (i.e., yes, Glühwein)

Wow, thanks Tursi, I didn't know this page. I wished Thierry had some kind of index, but some pages are really only accessible though other pages. I'm currently too drunk to go through this carefully, but I'll check it out tomorrow.

Here's the same segment with phi3 and the upper (MSB) four address lines. At least the signals seem consistent for each run. Note that I'm sampling with 25 MHz, which implies that each signal transition (i.e., vertical line) could be off by 40 ns in each direction. Still, the WE* pulse is 340 ns wide and thus not a figment of the measurement. And looking at phi3, it seems that this is business as usual for the TI. The address of the write seems to be >8???. Could this be the result of an access by operand *Rn+, where registers are located in scratchpad RAM >83xx? Still, it's odd that it's in the same MEMEN* cycle.

Yes, phi3 was my initial thought as well, but I was kind of reluctant to (somewhat painfully) rewire my test harness. But I'll try it tonight. The first address read (A) is somewhere in >6000->6020 (hence the consecutive reading of two bytes). I have no idea what (B) reads (I cannot capture the entire address bus), but it looks like just one byte.

While testing a few things with the FinalGROM 99, I caught some strange-looking (to me) bus signals, which I recorded with my logic analyzer (attached to the side port, for simplicity). Read cycle (A) is a read access to the FinalGROM's GPL header. You'll notice that the entire MEMEN* cycle is longer than 2 us, and that some short WE* burst precedes the actual read access (DBIN high for 2us). What the hell is that write doing there? Not every cart read access has this extra write ... But these short writes do seem fairly common. In cycle (B) I caught another write followed by a read, again to the same address (only LSB A0 is shown in the graph). Can someone explain to me what is happening here? I've heard of read-before-write, but not the other way around ...

You asked about native GPL assemblers, but note that there is also a cross GPL assembler.

I'm looking at Thierry's page on BASIC argument parsing, and it's atrocious (the mechanism, not the page). What I get is that I have to use various console routines XML >1x to parse BASIC, and that some routines won't work for Extended BASIC. Has anyone ever done this successfully and can provide further details? If I use those XML >1x routines, what are their input arguments, and their result values? What do I have to use for Extended BASIC instead, especially for the symbol table?

It's not a straight lookup, unless you want a lookup table with 65536 entries. Each instruction format has a particular opcode length associated, so you have to iterate over all formats and see if the word you have anded with the format's opcode length matches any opcode with that format. To see an implementation, see xda99.py in the xdt99 suite, search for "def decode".