Jump to content

jedimatt42

+AtariAge Subscriber
  • Content Count

    2,869
  • Joined

  • Last visited

  • Days Won

    3

jedimatt42 last won the day on May 7 2017

jedimatt42 had the most liked content!

Community Reputation

3,205 Excellent

2 Followers

About jedimatt42

  • Rank
    River Patroller
  • Birthday 05/15/1973

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Beaverton, OR
  • Interests
    Programming, old and new.
    The world of Arduino.
    My TI.
  • Currently Playing
    Mousing around on my TI-99/4A

Recent Profile Visitors

16,398 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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...
  6. 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 )
  7. @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.
  8. 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.
  9. @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.
  10. 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.
  11. Oh... https://www.nameacronym.net/#results Maybe Force is an acronym: Flaming Online Runtime Client Emoticons That's plausible?
  12. 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.
  13. 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.
  14. 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.
  15. If the switch is off for 9640 powered, what does that mean? Is there a place to apply external power?
×
×
  • Create New...