Jump to content

PeteE

Members
  • Posts

    541
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by PeteE

  1. That reminds me, there was this guy Rikkles in the RoA discord that made a customized version of classic99 that adds the shared memory feature so that Grid Cartographer could read the maps in Realms of Antiquity: https://github.com/hasseily/classic99 I saw it in the RoA discord: https://discord.com/channels/644060281923960864/827590732596117524/833964361520906260 Maybe that will work for you @SteveB I presume it was created with Tursi's blessing
  2. It's from the BLWP assembly instruction. For the application logo, I was thinking of picture of a bullwhip and a texas longhorn (not the sports team)
  3. @SteveB I'm already thinking about TiCodEd integration, and I tried implementing the Paste functionality that Classic99 uses. It seems to work except it exposed an emulation error when running XB. After I get that fixed I can send you a compiled binary to play with. Which OS do you use?
  4. As some of you already know, I have been working on my own emulator for quite some time. Mostly as an educational endeavor to test my knowledge of how our lovely machine works, and also to benchmark my own opinionated optimizations and debugging techniques. It is written in C and uses SDL for display, and has a bespoke UI for cross-platform capability. I've gotten a lot of ideas from other emulators: Classic99 (thanks Tursi), JS99er (thanks Rasmus), DS99 (thanks Dave), 32blit-ti99 (thanks Erik) I'm not ready to publish binaries yet, but the code is here if you want to try compiling it yourself: https://github.com/peberlein/bulwip This is very much a work-in-progress, and I'm aware you can't do much with only cartridge support. I'm currently focused on making the debugger useful for developing cartridge software and showing a listing file to navigate while stepping through the code.
  5. That's a neat way of looking at it.. but I don't think you should tell anyone the other way is wrong. 8000 Scratchpad RAM and memory-mapped devices A000 C000 24K RAM E000 0000 ROM 2000 8K RAM 4000 DSR 6000 Cartridge ROM Edit: Context is important. I shouldn't have poked the bear
  6. The .ctg format only works with TI99/Sim emulator. For Classic99, you need .bin files. The Blasto one is here: (phm3032G.BIN)
  7. https://github.com/Speccery/StrangeCart-Doc
  8. Oops, I wasn't clear in my statement, and I don't have my DS with me in the office, so I think you may already have what I intended to write. I think the problem is this: "But as soon as you press the next key, it "releases" the FCTN/CTRL/SHIFT" it should be "as soon as you release the next key" - both FCTN and the next key need to be held from the TI point of view at the same time. If that is how it already works, I apologize for not verifying it myself.
  9. Can you make the FCTN,CTRL,SHIFT keys "sticky" (somewhat like shift key on modern phones keyboard) where you can press FCTN and it stays pressed until the next key is pressed and released. That would get around the limitation of the resistive touchscreen. The FCTN key on the screen could highlight/invert color to indicate that it is held in the "sticky" state. Pressing FCTN again (without pressing a different key) would clear the sticky state.
  10. Here's another banked cartridge project that runs on unexpanded console: https://github.com/peberlein/bounce-n-pounce/blob/master/bnp.asm (Bounce'n'Pounce is unrelated to Bouncy's obstacle course, despite the name) I found the DORG directive useful, so I can declare variables using a label with DATA or BYTE statements in the 256B memory space at >8300. The variables still need to be initialized elsewhere, but it does make it easier than calculating variable addresses manually.
  11. 100 call clear::call screen(16)::call magnify(4)::call char(32,"CCCCCCCCCCCCCCCC")::c=5::s=3 110 call char(88,"0000000000000000000000000000000000000000000000000000FCFCFCFCFFFF") 120 call char(92,"000003030F0F3F3FFFFF000000000000FCFCFCFCFCFCFCFCFCFCC0C0C0C0C0F0") 130 call char(96,"7F7F0000000000000000000000000000FFFF0000000000000000000000000000") 140 for i=0 to 3 150 call sprite(#i*2+1,88,c,i*24+1,i*64+18,0,s,#i*2+2,92,c,33+i*24,i*64+16,0,s,#i+9,96,c,150+i*10,i*64+64,0,s) 160 next i 170 call color(1,2,16)::for i=0 to 2000::next i 180 call color(1,16,16)::for i=0 to 1000::next i::goto 170 run Pigeon neck illusion, inspired by this
  12. Great work! I am getting 60+ FPS on my DS lite.
  13. I'll always remember the story of him and Sparkdrummer flying into Portland for FW'17 and since they didn't bring a monitor on the plane, they went to a Goodwill store and got one for a few bucks, so that Airshack could present his game "Sparkdrummer's Challenge". And gave the monitor to Omega after the event.
  14. This makes me so sad, I don't even know what to say. I met James/Airshack in person at Fest West'17, and saw him again later at PRGE a few years ago. I loved seeing the games he made, and seeing the progress and results of his learning to program assembly language. Such a nice guy, he will be missed.
  15. Here are the two that I use: mbtest.bin from here, TI9900_CPU_Test.txt converted to run in cartridge https://forums.atariage.com/topic/345582-what-are-your-ti-99-or-ti-99-adjacent-plans-or-resolutions-for-2023/?do=findComment&comment=5180258 cputestc.bin from here https://forums.atariage.com/topic/263955-tms9900-cpu-core-creation-attempt/?do=findComment&comment=4241686
  16. I think it could be expressed using three variables: speed, counter and a threshold. The speed is added to the counter, and while the counter exceeds the threshold, move the object and subtract the threshold from the counter. If the object moves 1px every frame, then the speed will be equal to the threshold. If the object moves more than 1px every frame, the speed is greater than the threshold, etc. With threshold = 100: Speed = 25, move 1px every 4 frames Speed = 33, move 1px every 3 frames (close enough) Speed = 20, move 1px every 5 frames Speed = 200, move 2px every frame Speed = 400, move 4px every frame Something like this code: ; initialization LI R0, 10 ; speed CLR R1 ; counter ; game loop GAMELP A R0, R1 ; add speed to counter CHKMOV ; check if object can move this frame CI R1, 100 ; counter < threshold? JL NOMOVE AI R1,-100 ; subtract threshold from counter BL @MOVOBJ ; move object 1px JMP CHKMOV NOMOVE ; game loop continues ; wait for vsync BL @VSYNC JMP GAMELP
  17. @llabnip My work in progress emulator is here: https://www.github.com/peberlein/bulwip Feel free to use anything from cpu.c that you deem useful for your own 9900 code. The cycle timing isn't accurate yet. It also relies an having CLZ hardware instruction for 9900 opcode decoding, not sure if the DS ARM CPU has that or not.
  18. In addition to this, transparent sprites (with color = 0) are still checked for collision, even though the pixels are not drawn into the scanline.
  19. It's a work in progress (Sorry for the derail)
  20. I got it to work on my DSLite. Speed seems not too bad, is there a way to show the FPS?
  21. Thanks for this. My emulator currently only handles cartridges so I had to make add a loader in cart space. And sure enough, it revealed that my JHE was incorrectly jump if high AND equal. 🤜😆 The next hurdle was XOP, and with that it passes the test. I finished multicolor mode (that everybody wants) and 5th sprite per line detection, and finally it can run the megademo.
  22. What techniques did you use to get it fast? I'm working on my own 9900 CPU emulator and am also trying to make it very efficient. Speccery also has an MIT-licensed emulator that he optimized for running on the 32Blit handheld dev console. So to run your emulator on a DS Lite, I would need a R4 card?
  23. @speccery Thanks for the detailed write-up. I was curious if the ROM emulation would be fast enough despite multiplexing the address and data bus. How would you say the Pico board compares to your StrangeCart? I'm assuming the Pico cart could use the same LI instruction method of writing data quickly to the VDP. Maybe the second core could be rendering/generating the LI instructions as the first core serves the bus. This has my project idea neurons tingling.
  24. I'm using XDT99 assembler and its banking features. Here's the bankswitch code I'm currently using in my game, which does not require expansion RAM; all banking is done by the ROM program in the 6000-7FFF space. I created a separate label for each bank, since I wanted to minimize register usage during bankswitching, the tradeoff is using a bit of ROM space in all banks. I'm not saying you have to do it this way, since you are planning to use expansion RAM, these techniques would be unnecessary. * Cartridge memory space CARTAD EQU >6000 ; Cartridge address space CARTED EQU CARTAD+>1FFF ; Cartridge space end BANK0W EQU CARTAD ; Bank 0 write address BANK1W EQU CARTAD+2 ; Bank 1 write address BANK2W EQU CARTAD+4 ; Bank 2 write address BANK3W EQU CARTAD+6 ; Bank 3 write address BANK4W EQU CARTAD+8 ; Bank 4 write address BANK5W EQU CARTAD+10 ; Bank 5 write address BANK6W EQU CARTAD+12 ; Bank 6 write address BANK7W EQU CARTAD+14 ; Bank 7 write address SAVE CARTAD,CARTAD+>2000 ; Assembler writes full 8K banks AORG CARTAD *************************************************************** BANK ALL *************************************************************** BYTE >AA ; Standard header BYTE >00 ; Version number 1 BYTE >01 ; Number of programs (optional) BYTE >00 ; Reserved (for FG99 this can be G,R,or X) DATA >0000 ; Pointer to power-up list DATA PRGLST ; Pointer to program list DATA >0000 ; Pointer to DSR list ;DATA >0000 ; Pointer to subprogram list (this doubles as next program list entry) PRGLST DATA >0000 ; Next program list entry DATA START ; Program start address STRI 'LEGEND OF TILDA' EVEN START CLR @BANK0W JMP x#MAIN ; Note: BANKnX must be followed by DATA destination address in new bank ; Return address R11 is modified to return after DATA ; otherwise BANKn must be called with target address in R13 BANK1X MOV *R11+,R13 BANK1 CLR @BANK1W ; sprload.asm, enemload.asm B *R13 BANK2X MOV *R11+,R13 BANK2 CLR @BANK2W ; map.asm B *R13 BANK3X MOV *R11+,R13 BANK3 CLR @BANK3W ; tiles.asm B *R13 BANK4X MOV *R11+,R13 BANK4 CLR @BANK4W ; herospr.asm, keys.asm, gameover.asm B *R13 BANK5X MOV *R11+,R13 BANK5 CLR @BANK5W ; movobj.asm, status.asm B *R13 BANK6X MOV *R11+,R13 BANK6 CLR @BANK6W B *R13 BANK7X MOV *R11+,R13 BANK7 CLR @BANK7W B *R13 * Bank 0 last, to take advantage of JMP for returning to bank 0 BANK0X MOV *R11+,R13 BANK0 CLR @BANK0W ; main.asm, hero.asm, scroll.asm B *R13 *************************************************************** BANK 0 *************************************************************** MAIN LIMI 0 ; Interrupts off LWPI WRKSP ; Set workspace pointer ; example of using bank switch with target address in following data statement BL @BANK3X ; tiles.asm DATA x#LTITLE ; Load title tiles in bank3 ; ... *************************************************************** BANK 3 *************************************************************** LTITLE MOV R11,R13 ; Save return address ; code to load title tile graphics JMP BANK0 ; Return to saved address in R13 bank 0 ; could also use "B @BANK0" if JMP can't reach
×
×
  • Create New...