Jump to content

Tursi

Members
  • Posts

    8,644
  • Joined

  • Last visited

  • Days Won

    9

Tursi last won the day on December 27 2023

Tursi had the most liked content!

6 Followers

About Tursi

  • Birthday 11/29/1971

Contact / Social Media

Profile Information

  • Custom Status
    HarmlessLion
  • Gender
    Male
  • Location
    YYC
  • Interests
    Buy me a Kofi! https://Ko-fi.com/tursilion

    Or fill in my 'SurveyWalrus' and help choose my next task!
    https://harmlesslion.com/cgi-bin/walrusquery.cgi
  • Currently Playing
    Current Project: Website update
  • Playing Next
    Next project (per survey): Finish Super Space Acer ColecoVision

Recent Profile Visitors

34,008 profile views

Tursi's Achievements

Quadrunner

Quadrunner (9/9)

10.1k

Reputation

  1. I suspect my local store is already starting to recognize me as "that scruffy guy who swears at the computer checkout". They really don't need it trying to have a conversation with me.
  2. The biggest difference really will be that my tool compresses the audio, so it will eat less memory, and it will be able to handle faster sound changes than BASIC. But if BASIC/XB CALL SOUNDs work for your project, by all means! I don't know how stable or not my XB player is - I'm not sure if it was ever used.
  3. That's probably the only way to be universal. The FinalGROM could run all startup functions when it builds the menu, but there's a very likely chance that a lot of combinations would cause other problems. Could define a special format that the FinalGROM could look for, but then existing ones wouldn't see it anyway. Probably best to keep it a cartridges special feature
  4. Lol, that's brilliant! I'mma steal that idea if that's cool?
  5. I could probably write a tool to do the conversion... but I won't be able to for some weeks.
  6. I think you're asking multiple questions here. On the subject of TIFILES headers - yeah. If you are moving files from the PC to a TI disk, then you need a header to tell the emulated TI what it is. And if you move it back to the PC, no, the testplayer doesn't know what a TIFILES header it and it won't make sense of the data. To load your music will require you to do some work. Once you have the SBF file, you need to convert it to something that can be loaded by the XB loader, and yes, you need to add the DEF label. The SBF file on the PC side is a binary file. If you look at guile.a99, you'll note the comment: * Data file guile_gb.vgz.sbf - Sep 04, 2021 (DEF and END added by hand) The datafile itself was created by my bin2inc tool, which takes a binary file and creates the assembly source that you see there. https://harmlesslion.com/software/bin2inc/ The command line in this case was: bin2inc guile_gb.vgz.sbf guile.a99 MUSIC TI bin2inc - command guile_gb.vgz.sbf - input file guile.a99 - output file MUSIC - label to attach to the data TI - output TI assembly format I then opened guile.a99 in notepad, and added the " DEF MUSIC" line to the start, and the " END" directive to the end so that it could be assembled as a stand-alone module. In this case I probably used WinAsm994A to assemble it into an object file, which I dropped into the Classic99 folder. It should be possible to use xdt99 as well, though I don't have the command line handy. Note in either case while you have TI formatted source code, it's still a Windows PC file. If you use the above tools, the output is also a Windows (or Linux) text file, not a TI file. There's lots of ways to convert files to TI format. For my part I usually just use Classic99... though this trick will only work with source and uncompressed object files (mind you, I believe XB can only load uncompressed anyway?) if you have either of those, you can just load up Editor/Assembler and use the EDIT/PRINT function - source file is your input (ie: DSK1.GUILE.OBJ), and for the printer just specify the output file (ie: DSK1.GUILEO). Classic99 will read the windows file and write the TI version. For other tools consult their creators. Once it's correctly in TI format, it should be loadable in XB. The DEF MUSIC will make the label available to the XB linker as described. All that said, the example guile_gb.vzg.sbf should play fine in the test player. It does for me! So in short, the intent is to do most of this on the PC side - any tool can be substituted but I list the tools I used: 1) create your SBF file 2) Convert to assembly source code (bin2inc) 3) Assemble to TI uncompressed object file (WinAsm99) 4) Convert to TI format (Classic99) 5) Load as per the readme
  7. Well, that's their own stupidity. There's nothing in the task that requires any kind of AI. Though I'd be happy if the fucking thing would stop telling me to take my groceries over and over again while I'm loading the bags. If the scale is sensitive enough to detect an extra paper bag on it, it can certainly tell that the scale is getting lighter as I remove items.
  8. For my two bits, the only time you would really use BLWP is if you want to use a separate workspace. If you can make do with the same 16 registers throughout, then BL is much faster. The idea is that BLWP and RTWP let you switch to an entirely different context, then back again. So it's good if the code needs to be distinct from the rest of the program. (Interrupts work this way, for that reason.) It makes for arguably cleaner code, but if you're already writing in assembly language I'd argue that battle was already lost.
  9. The easy answer is to just buy the board Jim made. It's only a couple dollars more on the AVR but everything's done, tested, and working.
  10. Yeah. In theory, any AVR with enough I/O pins should work. In practice I remember trying a 168 and having some trouble with it, but I didn't dig too deeply. AVRs often have output current limits on some pins and I suspected that was the problem there, but it was just a single afternoon's test. I think I still have a tube of 168s somewhere. The minimal connection is 11 I/O pins (8 data, 3 control), every other function we can turn on or off as needed. IIRC it's usually dual purposed analog pins or the reset pin that cause the reduced current, if that is indeed the issue. The ATMega168 has 23 I/O pins so shouldn't have any trouble there. You'd also get EEPROM save memory for free using this approach, if you wanted it. For pin compatible the cheapest option looks like the ATMega16, which has just 16K but the same pinout as the 1284. Showing $4.33 at Mouser. This is also the controller I used for the PS/2 keyboard adapter - for the same reason. Glueless connection (but I did need to overclock it to 20Mhz with an external clock there). If you don't mind moving away from DIP entirely to surface mount you can get as small as the ATMega808 - this is the newer Mega-0 line and needs testing. Faster clock and such, but the 808 has 8k of flash, 1k of RAM, and 256 bytes of EEPROM (high score data! ) and has 23 I/O pins. These go for 97 cents in SOIC packaging - but we'd need to update the code to the new pinout and make sure it's still electrically compatible. This is probably as small as it's reasonable to go for a boot GROM and yet it still has enough pins left over for UART, I/O, ADC... (and, looks like the same family goes up to 48KB, so there's even program space available). The datasheet looks good. We'd have to test it though. I get the desire not to waste space... we're probably going to ship Super Space Acer on Ubercart* just because it already exists, despite the pitifully small amount of the ATMega it needs. But also happy to help get the smaller design working, though I probably need to build a new adapter for testing. The Mega-0 line looks like a nice upgrade. That said too, other people have also made microcontroller GROM emulation. And there's nothing saying this code can't be ported to just about anything with some effort. (* could be worse - my first plan was just to burn the gigacarts for it! ) Although... if you're going Ghostbusters... The ATMega's ADC inputs, if left floating, are insanely sensitive. I was able to alter the values in the test code by hovering my hand near them. If your game loop can afford a couple of extra GROM accesses, you could read one of the ADCs and toggle some LEDs on the GPIO outputs to indicate strength. With a little tinfoil antenna glued to the inside of the shell it should pick up even through the plastic. The ghostly flicker would make for a crude PKE meter. (Or, hell, for that matter, we can just burn it into the AVR code - that way it's working all the time, game or no. )
  11. Yeah, I went through it with him and we found the exact point it fails at. For some reason in the middle of a generation it ends the sequence early and resets the output address. The new output address is off by one, though, and overwrites the previously output byte. I think Rich is trying several options and I suggested this one was worth a try cause I liked the rest of the toolchain and it would definitely be the fastest at compiling all of RXB
  12. Maybe a video starting from step 0 would help? Rich wants to try it but he's mostly experienced with the TI tools, not so much on the Windows side.
  13. I just have to add, this is /exactly/ what I developed the UberGROM for. The fact that people tried to use it as a flash cart is out of my hands, it was never meant for anything but people making new modules, and reproductions of Editor/Assembler and Extended BASIC -- because when I built it, we didn't have a way to do that. (Also, when I say UberGROM I mean only the AVR part -- the existing PCB board is thanks to Jim.) Now we have a wealth of options, so it's not as big a deal. But that's why I was disappointed. I was working really hard to release something that the community could use for both reproductions and new productions, both at a decent price point, and I not only got kicked in the ass for it, but to this day people are still talking about how it's too much and too expensive and too everything - when it's never been any of those things. People were just trying to use it as a flash cart and frustrated that it didn't do that, but I never said it would!
  14. That ATMega is $7 on Mouser, where are you seeing $25? https://www.mouser.com/ProductDetail/Microchip-Technology/ATMEGA1284-PU?qs=lwdSMh1%2FoYI%2FXs3D3l%2Fp1w%3D%3D The entire point of the system was to size it to the GROM you need. You can use smaller ones for even less than that. Smaller pin-compatible parts go all the way down to $3. If you don't mind laying out your own PCB you can do it under a dollar. Going to be hard to reproduce that price point in discrete components, which was the point of building it on the AVR line. It attaches without glue to the TI bus and can literally be the only component on the board, if you desire.
×
×
  • Create New...