-
Posts
4,304 -
Joined
-
Last visited
-
Days Won
4
jedimatt42 last won the day on May 6 2023
jedimatt42 had the most liked content!
About jedimatt42
- Birthday 05/15/1973
Contact / Social Media
- Website
Profile Information
-
Gender
Male
-
Location
Beaverton, OR
-
Interests
Programming, old and new.
My TI. -
Currently Playing
Mousing around on my TI-99/4A
jedimatt42's Achievements
River Patroller (8/9)
5.6k
Reputation
-
I found my bug, and it was mine alone... The compiler will issue calls to memcpy when performing things like literal string assignments on the stack... so I tuck the memcpy routine into the pre-amble of all my cartridge banks. But for my external executables, I did something dumb, and had the memcpy symbol literally defined in the linkfile. Now that the compiler has changed, that address was invalid. Things work once it is set to the correct address. I need to find a way to define that dynamically... Each executable I've written for ForceCommand has a clone of this bad linkfile. Edit: Looks like linker scripts can use INCLUDE, so my sdk should probably just include a generated linkerscript to include...
-
This looks great. Next time I open up my 4A, I may be inspired to do something similar for some of my odd ports. I like how you lean on the existing supports inside the case!
-
This is NOT the bug I'm chasing, it turns out... but a clever compiler doing the right thing. It didn't match the patterns I was expecting, but in trying to explain it, I realize this is just smart assembly that it generated. I'm posting this anyway cause maybe it'll help someone else when reading their .s files... The following is written before I realized... --------------------------- Ok, everything was pretty happy, but I'm chasing a bug I believe the optimizer (-Os) is introducing into VIRGIL99 ( Gemini browser for ForceCommand ) So, I have this sys call macro for defining API calls from external executables into the ForceCommand API FROM: https://github.com/jedimatt42/fcmd/blob/e3c3f68cff5d66b1317333f6f79f681f4162695b/fc_api_template#L14 #define FC_SYS *(int *)0x2000 #define DECL_FC_API_CALL(index, func, return_type, arg_sig, args) \ static inline return_type func arg_sig \ { \ __asm__("li r0,%0 ; " #func \ : \ : "i"(index)); \ return_type(*tramp) arg_sig = (return_type(*) arg_sig)FC_SYS; \ return tramp args; \ } My fcsdk code generator produces fc_api.h with declarations using this macro : #define FC_STRCPY 0x2e ... // function: char * fc_strcpy(char *d, const char *s) DECL_FC_API_CALL(FC_STRCPY, fc_strcpy, char *, (char *d, const char *s), (d, s)) I call a lot of fc_strcpy in virgil99's b0_keyboard.c So it factored the code generated by my macro, into a function it calls fc_strcpy, instead of in-lining it everywhere it is used. However, the function generated uses a 'b' instead of 'bl' to call my trampoline ( the result of the line in the macro "return tramp args;" ( looks funny but the args parameter to the macro has the parenthesis that make it a function call. ) 'tramp' is a function pointer to my cartridge entry point for api calls... the address of which is stored at 0x2000 So, most of the time, the function is in-lined, and the code generated looks something like: * Begin inline assembler code * 576 "/home/matthew/dev/gitlab/jedimatt42/fcmd/example/gcc/fcsdk/fc_api.h" 1 li r0,>3B ; fc_strset * 0 "" 2 * End of inline assembler code mov r10, r14 ai r14, >A li r3, >100 clr r2 mov r14, r1 mov @>2000, r4 bl *r4 this is good... this one works... The API ID is loaded into r0, then arguments for the real function call are setup, and then my trampoline is called by the 'bl *r4' - this trampoline consumes r0 before any C usages of r0 occur... But that 'extracted' fc_strcpy doesn't generate correctly: fc_strcpy * Begin inline assembler code * 537 "/home/matthew/dev/gitlab/jedimatt42/fcmd/example/gcc/fcsdk/fc_api.h" 1 li r0,>2E ; fc_strcpy * 0 "" 2 * End of inline assembler code mov @>2000, r3 b *r3 The 'b' instead of 'bl' at the end, and then there is no return either... The assembly calling this looks ok: mov r14, r2 li r1, state+286 bl @fc_strcpy Oh, no, I'm totally wrong... by using a trivial 'b', r11 from the bl @fc_strcpy is still set to return to that caller, and all of this should work...
-
No. you need a XC95144XL-TQ100 -> https://github.com/jedimatt42/tipi/wiki/Sideport-BOM
-
https://github.com/jedimatt42/tipi/wiki/Troubleshooting#troubleshooting-tipi-hardware
-
In my experience, the CPLD pins that connect to the PI end up fried. It usually acts like it is fine but can no longer signal the PI... The fix has always been to replace the CPLD, and then reprogram it. The PI Imager should just be placing a wpa_supplicant on the boot partition. that shouldn't interfere with bootup. You should be able to ssh and observe that nothing is happening in the /var/log/tipi/tipi.log . CALL TIPI/running TIPICFG never needs to happen if you don't want network access... or if you have used the wpa_supplicant to configure your wifi, or used an Ethernet cable....
-
Pi Pico[W] Peripheral Expansion Box Side Port Device
jedimatt42 replied to JasonACT's topic in TI-99/4A Development
'compatibility' is a key word you hadn't used when making your case against my suggestion. I had no idea you were aiming for compatibility with TIPI besides the mentioned mouse support. Going back to the beginning of this thread, there is really no discussion of what or how it is characterized as compatible... I'm sorry for the mis-understanding. In what ways is this compatible? -
Pi Pico[W] Peripheral Expansion Box Side Port Device
jedimatt42 replied to JasonACT's topic in TI-99/4A Development
XB removed searching DSR's for CALLs unless in immediate mode. So they cannot be used in DSK1.LOAD programs. I only reply as to not leave anyone misinformed. -
Pi Pico[W] Peripheral Expansion Box Side Port Device
jedimatt42 replied to JasonACT's topic in TI-99/4A Development
All I care about is our users not being confused by 2 different things called the same thing. Your command is a superset of mine. Different is different. There is no technical reason for the name to be the same. This was just a suggestion in the interest of the community. It seemed like a reasonable and cheap disambiguation. I won't bring it up to you again. -
-Os works for me too. I recall when I started with gcc for the TI, that it didn't. For ForceCommand this shaved 10k of instructions out. It was around 80k. I tried the no-function-cse option, and in my case since most of my function calls are to my trampoline, it actually grew in size a little tiny bit (less than 256 bytes). I was shocked how small the difference was. So I guess I save a word per call by having the function address in a register, but then I have more register gymnastics to make up for that.
-
Thanks, @khanivore Looking at all my use of __packed__ it seems I used it all over the place without really considering the need. Things seem to be working well with all the __packed__ removed. I don't think any of my structs actually needed it. My environment variable system works, my cached DSR info works, which meant traversing all the ROMs works... actual file IO works. A ton more to test, but that's a good start. Code should be smaller and faster now too. There was a ton of that accessing ints as a pair of bytes stuff going on before...
-
Pi Pico[W] Peripheral Expansion Box Side Port Device
jedimatt42 replied to JasonACT's topic in TI-99/4A Development
Right, your CALL TIPI does SO MUCH MORE, making my point. This is all cool stuff, but I think overloading the name does yourself and the community a disservice. -
Looks like I'm having trouble with packed structs. struct __attribute__((__packed__)) DeviceRomHeader { unsigned char flag; unsigned char version; unsigned int reserved1; struct EntryLink* powerlnk; struct NameLink* userlnk; struct NameLink* dsrlnk; struct NameLink* basiclnk; struct EntryLink* interruptlnk; unsigned int* gromsomething; }; When I declare the ROM in an expansion card as that struct, and then read the value of the dsrlnk field, In classic99 ( it has it's own ROM for FIAD access, so I'm using that as reference ), then it reads the wrong value... with lots of byte manipulation instructions... struct DeviceRomHeader* dsrrom = (struct DeviceRomHeader*) 0x4000; The value of dsrrom->dsrlnk should be 0x4010, but I get 0x7010 in r1 before my function call... movb @>4008, r1 ; appears to copy the high byte of dsrrom->dsrlnk to high byte of r1 sla r1, >8 ; slide that over to the high byte? but isn't it already there? so, move garbage from low byte of r1 to high byte from an earlier function call return value. movb @>4009, r14 ; copy the low byte of dsrrom->dsrlnk to r14 high byte. srl r14, 8 ; slide the high byte into the low byte soc r1, r14 ; merge the high byte of r1 and the low byte of r14 to get the value in r14, except, r1 was corrupted already by that second instruction in this snippet. li r2, ab_uint2hex.1166 mov r2, @trampdata ; stash the call metadata ( banks and target address ) mov r14, r1 ; move r14 into argument 1 of the function call. r14 was wrong, so r1 will be wrong too. bl *r9 ; call the function that ( r9 will have the address of my trampoline in it, but that isn't relevant. ) I've been compiling with -O2 I believe the second instruction isn't accounting for the prior state of r1.
-
As the designer of the "32k sidecar" in the modern era, I didn't know anything about digital electronics when I began the project. I had no interest in a 32k sidecar for myself. But we had created a number of cartridge ROM images that were ROM loaders for programs that ran out of the 32k memory expansion. So my goals were: - to design something others could build ( This has proven to be a success, I only made a pretty small percentage of them in the wild, and others have re-designed it since ) - copying (mostly) the 32k SRAM PEB board design from ti-tech-pages, - add header pins instead of edge connectors for further exploration - and keep it cheap. There is now a 1meg sidecar in the same form-factor, commissioned by ArcadeShopper. So, for some years now, people have had choice.
-
For all models of TIPI, disk access requires the PI to be booted. Including the speech module shaped boards. There are versions of XB that may let you skip the loading of LOAD... You could hex edit your own XB, and change DSK occurrences to any other 3 letters and that would stop trying to load. You could turn on the PI. You could put a switch on the OE of the 74'245 chip on the board to pull it high when you want the TIPI disabled. You could build a different microcontroller that connects to the wires and returns failure codes back to the TIPI. You could rewrite the DSR to check for timeouts, and return DEVERR, slowing down all access for healthy operations. You could reprogram the CPLD to require a state on one of the test pads before enabling the TIPI's bus. ... There are lots of choices.