jedimatt42

My telnet code doesn't move the cursor... it sends a backspace. The program you are interacting with on the other end of the telnet session is responding to the backspace with something weird. What are you running? Bash? A few years ago, backspace worked correctly in bash on Raspbian. https://github.com/jedimatt42/tipi/blob/1ea33e66d7209a47d5defbbee2fe5d7da24af3aa/examples/telnet/terminal.c#L538 The code is written to send a standard backspace on left-arrow. My TI keyboard has a backspace button which is the same as FCTN-S. The code reads the 4A keyboard in mode 5. Notice how the telnet code is in the github repo under examples. That expresses the value of this code to me. it is meant as an example so people can see how to use the socket layer. You could consider the source a giant config file, and edit it. Linux has an stty erase 0x08 command that can be used to reconfigure some thing... I would try that first. 25 years ago, I used ^h on some systems as a backspace. hmm... I tried and it just doesn't work. There is no local echo, so this will take debugging.

It might already - My memory test detected 16Meg and so far well beyond 2Meg is passing. I originally thought this was an error, because I was printing the 'K' overtop the last digit. IDK if Classic99 does more... my test only examines up to 4096 pages. I get some questions about how to read the output here.... My memory test examines 32K at a time. So for SAMS, I page in 8 4K pages, then test the entire 32K address range. For other memory cards, they page 32k at a time... The 'addresses' on the screen are within the 9900 64K address range.

Same password... hopefully it is easy to remember for people that care about this system.

https://github.com/jedimatt42/ti994a-32kmemtest/releases I've made a 1.8 update to my program that adds a "quick check" mode. It performs a single pass over each memory cell.

Nobody willing has hardware or emulation support to fiddle with AMSTEST4. The reason my test program is painfully slow, is because AMSTEST4 was insufficient as a test. I have experience with it passing on bad hardware. It is not a proper test program in my opinion. It is only a quick inventory check. If there is demand for a fast test... well I'm just going to say that is not really a test... if there is desire for a size detection mode just reset the 4A after my test tells you your memory card size... It will have read, written, and read to every page to determine the capacity. The current interation (1.7) of my test should handle up to the full 16Meg, but I haven't received confirmation from @FALCOR4 who has the only SAMS above 1Meg, as far as I can tell. It is now using the same paging instructions as documented on Thiery's TI-Tech-Pages website, after a discussion with @FALCOR4 - I have not heard if he has tested this version.

They all require FAT family partitions, which wouldn't help this once in several years problem.

In Force Command, I scan the card ROMs once, and the crubase is a parameter to my dsrlnk. This allows me to let you copy between / load from 2 devices with the same name as distinct.

They can always use a classic XB The idea of new software being compatible with 100% of all things written on top of a different program is an irrational expectation, even if you've come extremely close! People don't print all that often anymore... the types of programs I recall were screen dump tools. It is my intention to eventually have an Load Interrupt triggered menu, but I don't actually use XB... so I'm holding my peace.

He's in! Sorry, I have to get in the habit of checking PMs before the meeting starts

If you are not doing so, you should bank switch before accessing the first bank. Physical hardware doesn't guarantee bank state on powerup.

I tried this when I first tested my Telnet program ... well, maybe not this particular CPM emulator, but one of the ones available... Seems like it would be cool to write a real CPM terminal, if you wanted to really use CPM... My Telnet client even on an F18A in 80 columns, doesn't work correctly with many CPM programs... CPM programs make assumptions about terminal size usually.

If you want the 32k board to pass power from the console to the 5v pin on the header expansion, just bridge the 3 jumpers for the TI/Ext power selection.. or if there is a switch there, bridge it... The schematic data file for the 32k is in some proprietary software, but there is a PDF somewhere... The schematic PDF is here: I don't have the data file for that anymore... the pcb layout was done in Robot Room copper connection, and it didn't base itself from a schematic, so the power rails aren't detailed... The robot room files are on my project page at jedimatt42.com

There is the SAVE program that comes with Editor Assembler... But if you didn't write the code with the symbols to support SAVE, it is a pain in the ... I usually just end up reading the tagged object code, to see where it loads, and how long it is... ( I have to re-learn each time ) I either find the docs for reading the format on ti-tech-pages or ninerpedia, and then use Classic99 's 'make' option in the debugger... set a break point to the 'start' address of the program, start the program, and then pick the make-ea5 menu item and make sure the addresses saved include the areas the program is linked into.

And actually looking at Lee's example, you don't need the header parts I have starting with interrupt list, and the cartridge port doesn't service interrupts... So I will revise that post.

Thanks @Lee Stewart, saved me some spec reading. Given a source file: cart.a99, the following xas99.py command will turn it into a bin that classic99 loads: xas99.py -b -R -L cart.lst -o cart_c.bin cart.a99 The contents of cart.a99 are: AORG >6000 ; cart roms headers start here BYTE >AA ; Standard Header BYTE >01 ; version DATA >0000 ; # of application programs / reserved DATA >0000 ; power up list - not used in cart ROM DATA menu1 ; user-program list (cart only) DATA >0000 ; dsr list ( not used in cart ROM ) DATA >0000 ; LVL2 DSRLNK & BASIC CALL subroutine list ( not used in cart ROM ) menu1: DATA >0000 ; next menu item address DATA prog ; program address BYTE 9 ; len of menu title TEXT 'AIR SHACK' ; title of cartridge EVEN ; this already is even, but best to stay out of trouble prog: blwp @>0000 ; reset the console - very small program This is a super simple program that resets the console.. you can set the breakpoint in the debugger to 601A and see it... Here is the listing output, if we add the -L cart.lst option to the xas99.py command... AS99 CROSS-ASSEMBLER VERSION 3.0.0 **** **** > cart.a99 0001 ; DSR ROM header 0002 AORG >6000 0003 0004 6000 AA BYTE >AA ; Standard Header 0005 6001 01 BYTE >01 ; version 0006 6002 0000 DATA >0000 ; # of application programs / reserved 0007 6004 0000 DATA >0000 ; power up list - not used in cart ROM 0008 6006 600C DATA menu1 ; user-program list (grom only) 0009 6008 0000 DATA >0000 ; dsr list ( not used in cart ROM ) 0010 600A 0000 DATA >0000 ; LVL2 DSRLNK & BASIC CALL subroutine list ( not used in cart ROM ) 0011 0012 menu1: 0013 600C 0000 DATA >0000 ; next menu item address 0014 600E 601A DATA prog ; program address 0015 6010 09 BYTE 9 ; len of menu title 0016 6011 41 TEXT 'AIR SHACK' ; title of cartridge 6012 4952 6014 2053 6016 4841 6018 434B 0017 0018 prog: 0019 601A 0420 54 blwp @>0000 ; reset the console - very small program 601C 0000 0020 You can see I got the breakpoint address from that second column, that shows the address of the blwp instruction. Also if you look at the parameter of the DATA prog statement, you see that prog is that address... The listing is extremely useful for debugging, so you can find those breakpoints.. The header can be confusing when you just want to make a ROM cartridge. This is because TI used the same header layout for DSR ROMs on expansion boards, and GROM, as it did for CART ROMs... But only some fields make sense in some contexts...

The -b option produces a 'binary' with no TI EA5 header, no TIFILES, no overhead... So it is suitable for building a loose cartridge ROM. I can work up an example... but you should have AORG 6000 , and then the rom header, which is like the GROM header, but slightly different. Be back in 30 minutes. ( I hope )

@Tursi I don't know when the ability to add a cartridge bank specifier to breakpoints was added, or if it has been there relatively forever, but Thank you! Also I just noticed, and updated to latest, but still see: The F3-Step-Over function to break after a BL doesn't respect the bank. 9 60B8 069D bl *R13 (20) 2 60BC D842 movb R2,@>0003(R1) (30) 0003 This is a snippet from the disasm window... The left column is the cartridge bank. then the program counter. I press F3 and end up still in bank 2, I just happen to also have code in bank 2 that ran from that next address before we would have fully returned to my caller.

Oops, I should fix that link... Does the megademo run from TIPI? That would be good news, it didn't last time I tried it.

@BJGuillot demonstrated this on a 4A using a QR code scanner, including demonstration of his QR code generator. At Fest West 2016 - He borrowed my USB keyboard enabled console, plugged in his scanner wand, and demonstrated reading into the TI the data from the QR code that his console displayed.

I don't know about these msxdev entries, but I know many of the new homebrew being released on cartridge for the MSX are from small teams with diverse skills as you describe.

Oh... https://www.nameacronym.net/#results Maybe Force is an acronym: Flaming Online Runtime Client Emoticons That's plausible?

If Disney ever asks, it is because the code is in a brute force style. And I didn't know 4A/Dos was once called Command DOS, I was just thinking about MSX/MS-DOS command.com.

Force Command is a GPL cart, with a powerup routine... but 99.9% of the code is in the ROM... the powerup routine just jumps over to the ROM. from within FCMD, the XB command writes a DV80 file to TIPI.FC.FC/XB containing the command to run the parameter. locks the F18A, but otherwise does not prepare VDP. The console's reset routine is not executed, but the FinalGROM is instructed to load a cartridge, and then the entry point address from the GPL program header is 'returned to'... GPLWS R6 is loaded with the GROM address and we branch to >0060 : https://github.com/jedimatt42/fcmd/blob/423b8ed1413a8f841407c5dba115e394184b1430/b1cp_fg99.asm#L39 (except, if XBADDR is 0, then we just reset the console) Now magic happens -- if you pull the curtain back, a file exists in TIPI.FC called LOAD, and DSK1 is mapped to TIPI.FC... so the XB should find and load the file... The LOAD program parses that DV80 that was written earlier, determines if it should unmap DSK1. or let the TIPI automap feature kick in, and then RUN's that DV80 file. Since that file ends in /XB, TIPI uses xbas99 to turn it into a PROGRAM image file when the LOAD opcode tries to read it. Now we are running the program that was passed to Force Command's XB command. Life is great, cause you are in XB, where you grew up. Then you become discontent and want to leave... so you run FCMDXB, an assembly program embedded in a BASIC file. The FCMDXB program is this assembly code : https://github.com/jedimatt42/fcmd/blob/423b8ed1413a8f841407c5dba115e394184b1430/FC/reload_fcmd.asm#L2 embedded in a XB PROGRAM image using : xas99.py --embed-xb -R -L assemblexb.lst -o FCMD.xb reload_fcmd.asm That code works the same as how we got into the extended basic cartridge, instructing the finalGrom to load the FCMDG.bin, and then reset the console. The powerup routine in my GROM takes over, and you end up back in Force Command. ----------- The remaining intermittent issue that requires a manual reset to get back into Force Command is due to the request to load the cartridge in the finalGrom returns before the cartridge is loaded. Returns is the wrong concept.. you never actual give control to the finalGrom, you just drop a hint that you want something done, and it hears you and does it... but you have to determine completion yourself... The example from Ralph B. just waits a little bit, and then looks in ROM space to see if things are populated. I need to experiment/study the final grom source to see if I an check all the banks without disturbing the load operation. This got a lot worse when I switched to a 128k rom.

Well, on the TIPI they can be host os text files or DV80 TIFILES. And it will convert them to PROGRAM image binaries if the LOAD DSR opcode is performed. xbas99 from the xdt99 suite also uses them for the text form of the BASIC program in the examples, but any name can be used. Those are the only 2 places I've encountered these filename usages.

If the switch is off for 9640 powered, what does that mean? Is there a place to apply external power?